Lock-In Lives in Your Tags

What I Built

The tag is a single Tealium template, not a family of tags. It’s built as a drop-in replacement for Tealium’s existing Oracle CX template, so wt.* parameter mappings, the E-Commerce extension and transaction event types carry over. On top, it adds four capabilities modeled on Adobe’s stack:

• An analytics layer for AppMeasurement’s core variables. Page variables, eVars and props, list and hierarchy variables, context data, success events with values and serialization, product-level merchandising variables, and s.tl-style link tracking. It doesn’t cover plug-ins or the full range of Adobe’s eVar expiration and allocation settings.
• Heartbeat-style media tracking. The same Tealium video calls the Adobe Heartbeat tag listens for, sent to Oracle Infinity as video sessions with ad breaks, chapters, quartiles, quality-of-service data and 10-second beacons.
• An identity service in the spirit of Adobe’s Visitor ID Service. A first-party visitor ID shared by every tag instance, customer IDs by namespace with authentication state, cross-domain hand-off and in-browser email hashing.
• A Web SDK-style event model. XDM-shaped objects flattened into Infinity parameters, identityMap-style identities, an alloy-style onBeforeEventSend hook, and one hit sent to several Infinity accounts, much like sending to several report suites.

Every hit lands in Oracle Infinity first. In this design, Unity and Responsys get their data server-side from Infinity rather than from the browser, so the tag puts identity keys on every hit once it has them: wt.dcsvid and a hashed email in wt.email_sha256. Eloqua is the one destination here with its own browser script, so the tag loads it, tracks the page view in your opt-in mode, and carries the Eloqua visitor GUID onto later Infinity hits.

What About Web SDK?

Adobe has its own answer to tag sprawl. Its Web SDK replaces AppMeasurement, the Visitor ID Service and the Target and Audience Manager libraries with one library, which sends a single payload to Adobe’s Edge Network. If the goal is fewer Adobe libraries, Web SDK gets you there.

It consolidates the code, not the dependency. Every event still goes to Adobe’s Edge Network and is routed by Adobe datastreams. Adobe’s event forwarding can pass that data on to other destinations, but it runs on Adobe’s Edge Network, so it stops when Adobe does.

Moving to Web SDK is also a migration of its own: a datastream, usually XDM schemas, and remapped variables. If you’re re-instrumenting anyway, decide first where the data should go. The tag takes either vocabulary: AppMeasurement-style mappings, as described below, or XDM-shaped data and identityMap-style IDs, with the gaps listed under Where It Stands.

How the Mapping Works

The tag reads the same Tealium mappings you would write for Adobe. Map a variable to pageName, eVar12 or contextData.member_tier, or set event5 when a value matches, and the tag knows what to do with it.

Serialization here is a client-side stand-in for Adobe’s server-side de-duplication, so it holds per browser, not across devices.

Data layer                                Mapping
page_name      "checkout:confirmation"    pageName
site_section   "checkout"                 channel
member_tier    "gold"                     eVar12
tealium_event  "purchase"                 purchase (event)
order_id       "ORD-10042"                order ID, via Tealium's E-Commerce extension

Media: Where Most Migrations Stall

Page analytics is the easy part. Video is where migrations stall, because media measurement is a state machine: sessions, ad pods, chapters, pauses that end sessions, and beacons that count time spent.

The tag meets players where they are:

• Players that already feed the Adobe Heartbeat tag. This tag reads the same Tealium video calls and built-in video variables, such as video_name and video_current_playhead, so the player doesn’t change. Two setup differences: bare event names such as play and pause need mapping to video_play and video_pause, which the Heartbeat tag does on its own, and custom media mappings need re-pointing.
• Players that call Adobe’s media API directly. A small media shim exposes the method surface of MediaHeartbeat 2.x and Media SDK 3.x for JavaScript. It can replace the Adobe tracker, wrap it so Adobe and Oracle both get every call, or patch Adobe’s globals so existing player code tees without edits. When wrapped, an Adobe failure can’t block Oracle.

Either way, Infinity receives sessions in its own video vocabulary. That means load, play, pause, resume, seek, buffer and bitrate events; ad break, ad and chapter events; quartiles for on-demand video; a beacon every 10 seconds by default; then complete or stop. A few details matter more than they look:

• Time played is counted, not inferred from the playhead. The tag accrues wall-clock time only while video is playing, ads included, so pauses, buffering and seeks don’t inflate it.
• Skipped quartiles aren’t credited. Seek past the halfway mark, and the 25% and 50% markers are recorded as passed but never sent.
• Ads don’t advance the content playhead. Ad events are labeled as ads, and the program’s position holds while an ad plays, provided the player keeps reporting the program’s position during the break.
• Long pauses end the session, as in Adobe. Thirty minutes by default, configurable.
• Quality of service rides along. Bitrate, frames per second, dropped frames and startup time travel with each event.

Run It Alongside Adobe First

Nobody should switch analytics vendors in one release. The tag is built to run beside Adobe until the numbers agree.

Most of this is Tealium configuration, so most steps are a publish you can roll back.

Where It Stands

Short version: the code exists, and live validation doesn’t yet.

That gap is the reason for the ask at the end of this post.

What Comes After the Tag

On Oracle, the aim is for behavioral data to sit next to what it needs to meet: customer profiles in Unity, orders and subscriptions in the database, and models running on the same infrastructure as the data. I mapped what a full move onto Oracle Cloud Infrastructure involves, workstream by workstream, in the OCI migration roadmap. Its CDP workstream moves collection from Adobe to Oracle; this is the tag for that step, and the safe route is the one above: mirror, prove parity, cut over.

It is also the prerequisite for something bigger. INBI argues that infrastructure will increasingly observe behavior directly, from delivery logs, API calls and server events. The client tag is how you get there.

An inference model needs ground truth to learn from and to be scored against. That ground truth comes from the client: a tag reporting what was actually played, clicked and bought, for sessions the infrastructure also logged. So the tag becomes the calibration instrument.

As server-side and inferred signals prove they match it, the client sends less. In the end it reports only what only the device knows: what was on screen, whether a video was paused or just buffered ahead, what happened offline.

The goal is one event contract through all of it, so reports read the same parameters whether the source is the browser, your servers or a model.