Home > Analytics > Server-Side Adobe Analytics Tracking via Tealium Event Stream

Server-Side Adobe Analytics Tracking via Tealium Event Stream

Image of man at track starting block with title text


Franz: “How about moving all your traditional client-side Adobe or Google Analytics tracking server-side?”

Britney: “Great, but then I have to hand that hard-fought Tag-Management-based freedom and control over my data flows back to developers and release cycles?”

Franz: “No, you can do server-side tracking AND keep Marketing in control over the tracking logic like in a TMS. This at least is another value proposition of Tealium’s ‘Universal Data Hub’, a Customer Data Platform.”

Very bold by Franz, right? We tested his claim.

Part 2 of this 3-part series on Tealium’s “Universal Data Hub” showed you how Tealium Universal Data Hub’s (UDH) “Data Layer Enrichment” gets historical Visitor data into your browser so you can use it for traditional JavaScript-based client-side tracking through your Tag Management System (TMS). For part 3, we go back to the future and back to where part 1 left off – it’s all about “server-side”.

Remember when I wrote in part 1 that all the Audience Stream connectors work server-to-server, so there is no additional load for the browser, and there are no browser-related problems like “user clicks to next page too quickly”, “user loses connection”, or “user uses ad blockers” (see “open issues/questions” on bottom of page on that).

So why not reduce the load on the browser even more, take advantage of Visitor Stitching and Omnichannel Imports (see part 1), and move all or most of your traditional client-side tracking server-side? That’s what Tealium promises: Via Universal Data Hub’s “Event Stream”, you can supposedly “server-side” all your Google or Adobe Analytics (and other tools) tracking without relying on your own servers and developers

Why Almost Nobody Does Server-Side Tracking

But usually, when switching to server-side tracking, the Marketing Technology Specialist gives up a lot of control to the development team (see e.g. Jan Exner’s post on the “era of server-side everything”). When server applications send data to your Analytics tools, the TMS as we know it, with all its flexibility, freedom and power, is shut out, because the TMS executes in the browser, not on a server. So you basically go back to the dark and inflexible world before Tag Managers where tracking implementation was 100% dependent on “IT” and changes had to wait for website releases. 

This is likely the main reason why almost nobody does server-side tracking even though the technological means for that have been there for a long time (e.g. Adobe’s Data Insertion API or Google’s Measurement Protocol). And then again, tracking stuff without a Tag Manager is harder and more tedious, you have to go out of your comfort zone, debugging is painful etc…

So the really interesting part about Tealium’s offering in this context is that you are supposed to keep that control because you can still flexibly prepare the data in the browser with your TMS, and even enhance it server-side via rules BEFORE it goes out to Analytics. “Best of both worlds” so to say. Sounds very enticing. Together with our competent agency Feld M, we tested how much of that is really true. We used Adobe Analytics as our testing system since it is the main Web Analytics tool at the company in question, a European E-Commerce site.

Tealium “Event Stream” Vs. “Audience Stream”

Event Stream Overview in Tealium Universal Data Hub

To get started, you go to “Event Stream” in UDH, not “Audience Stream”, the tool we have been focusing on in part 1 and 2.

Confusion Alert: There is an Audience-Stream-based Adobe Analytics connector as well. Audience Stream however can only send data when a user joins an Audience or if he/she is in an Audience at the start or end of a Visit. There is no “send on every Hit” criterion in an Audience Stream connector, and there is also no way to have a user join an Audience on every Hit. Moreover, the stitching can take a couple of seconds, and the connector is not called until after that. This is likely to mess up your Analytics tracking logs (they would be some seconds off).

In theory, you can use the Audience Stream connector to send occasional Visitor Attributes over to Adobe Analytics, but I haven’t found a good use case for this as it also messes up your Adobe clickstream data (e.g. it could create a Hit for a user after the Visit is already over, and if that Hit was not really a user interaction, Visits would get artificially lenghtened, Exit Pages may get overwritten etc.). 

Feature Audience Stream Event Stream (“Cloud Delivery”)
send data on every Hit or only some filtered Hits no yes
send stitched Visitor Attributes yes no
use data ingested via Omnichannel Attributes yes no, because those are also Visitor Attributes

So this comparison to Audience Stream also shows the limitations of Event Stream:

  • It simply forwards data from the Tealium Collect Tag, so the data to forward is limited to what you have in the Data Layer (plus Event Attributes in UDH) for a particular request. Instead of Tealium Collect, you can also send data into UDH via one of UDH’s APIs (go to part 1 to learn how UDH works in general if you are lost now) which is sensible for non-browser-based applications.
  • Event Stream thus does not benefit from Visitor Stitching, so it cannot send Visitor Attributes (which are based on stitching) (e.g. Lifetime Value, etc.). Likewise, data sent into UDH via Omni-Channel Imports is not supported.

Why so, you may ask? I think Event Stream (the server-to-server part of which is called “Cloud Delivery” btw) was made to send raw clickstream data somewhere as fast as possible to store and analyze it there. A more classical example for this is is our Amazon Kinesis real-time feed which is the basis for the raw data that our Data Science team works with.

Tealium EventStream gets the same data as Audience Stream, but simply forwards that data to 3rd-party tools server-side (data to forward can only be influenced via filters (Event Feeds) and minor Hit-level enrichments)

 

Setting up a Server-to-Server Connector for Adobe Analytics

  1. First of all, you create an “Event Feed” which filters out the requests that you want to forward to Adobe. This is a bit like creating a tag-firing rule in the TMS. Say we want to send data to Adobe Analytics on Cart Addition and Purchase Events only (which is what we did to start with to push only a few additional Server Calls into our Adobe license). In this case, we would create an Event Feed that filters for Events where Data Layer Variable “eec_action” (ecommerce interaction type) equals “purchase” or “add”. This logic and the variable names are probably different in your case, of course.

An example for an Event Feed, i.e. a “filtered” stream of Hit-level data

Eventually you will likely want to send all or almost all Events to Adobe, so you likely will use the pre-defined “All Events” Feed.

2. Now you add an Adobe Analytics Connector under “Connectors”, enter the details to start with (Fallback Report Suite ID, Data Collection Server Address etc.) and you are ready to go. 

3. Inside the connector, you select “Create Action”, you select the rule, i.e. the “Source” (=your Event Feed from step 1), and then you do the mapping.

Inside the Adobe Analytics Connector, you specify the mapping of Data Layer variables to Adobe variables, almost like in the Tag Management System

For Merchandising eVars (closest thing in GA are product dimensions), you cannot simply use the Array variables from your Data Layer like in Tealium iQ (TMS). Instead, since UDH stringifies all values (also Arrays) coming in from the Data Layer, you have to turn all of those variables back into “Arrays of Strings” in UDH (the green icons) before you can use them in the Adobe Analytics connector.

For basic variables, mapping is easy. It gets trickier (and buggier, although the most critical bugs were fixed in the meantime), the more complex your implementation is. Almost all typical Adobe variable types (Merchandising eVars, List Vars, etc.) are now offered, but the process to the current state was painful (see bottom). Tealium’s Adobe Analytics Connector mapping guide should now help you get over the bigger hurdles. 

Results, please!

So was that time invest worth it? Mostly, yes!

Because the server-side tracking seems to work better than the traditional client-based approach – in terms of completeness at least: We get 5-6 percent more Orders tracked now than with the traditional JS tag, and about 5 percent more Page Views

We assume this is mostly due to ad blockers or browser settings blocking Adobe and Google Analytics, but not Tealium UDH, but also because there is no logjam of tags waiting to get through to their tracking servers before the fast-clicking user navigates to the next page.

Example: Visits to Site Sections look the same relationally, but overall, tracking via UDH seems more complete (more Visits tracked)

Open Issues/Questions

The following is a mix of issues, caveats and questions that came up during the implementation or should be taken into account should you decide to set foot on server-side tracking terrain with Tealium UDH.

  1. Tealium’s QA of their own software: The general feeling was that we were guineapigs for Tealium of a complex new connector. And yes, of course it is complex, after all it is a connector for Adobe Analytics, the most powerful, but also probably the most complex Web Analytics tool when it comes to implementation.

    So we would have been fine with bugs in some edge cases, but our impression was that the connector had not been tested thoroughly by Tealium even for common cases like Merchandising eVars or Value Events.

    Once more, the fast pace and pressure of the online business seems to lead companies (Tealium is not alone here) to rush out exciting, but unfinished products and then outsource the QA to the client.

    This meant heavy additional costs and time for us which we cannot bill to Tealium’s QA department. Overall it took us about 4 months net to get to the current state of 90% readiness.

    On the other hand, Tealium support was there for us (thanks, Nathan Fleming) and Tealium added required functionality and fixed bugs based on our feedback.
     

  2. Value Events (i.e. Custom Metrics with values other than “1”, e.g. the discount per product in an order) do not work for us yet.
     
  3. Support of Marketing Cloud Visitor ID Field: Our test only used the legacy Adobe Visitor ID field. We haven’t had time to go into the MCVID setup which recently was added to Tealium’s documentation.
     
  4. Playing together with other Adobe tools: The Marketing Cloud Visitor ID is especially necessary when it comes to leveraging the synergies with other tools of Adobe’s Marketing Cloud, most importantly Adobe Target. Target requires a client-side implementation because layout changes for A/B Tests have to happen in the browser. But to be able to analyze A/B Tests in Analytics, you need to use the Marketing Cloud Visitor ID AND a shared “sdid” parameter fot both Target and Analytics. It would be interesting to see if that parameter is the only thing needed to make a combination of Target client-side & Analytics server-side work. We haven’t been able to test this yet.
     
  5. Tealium should get Audience Stream Capabilities into Event Stream or Event Stream capabilities into Audience Stream: As described, Event Stream does not support Visitor Stitching, Visitor Attributes or Omni-Channel data. This however would be absolutely super-powerful and a really convincing USP because you’d have both, the power of Visitor Stitching plus server-side Hit-level tracking.
  6. Ad Blockers: Even though the tracking seems to be more complete via UDH than via traditional JS, there are still some Ad Blockers out there which block Tealium iQ by default (thus no request gets to UDH, thus nothing for Event Stream to forward to Analytics). This makes the tracking still less complete than “traditional” server-side tracking where you hand over the control to your dev team. This could maybe be overcome with some proxy server, but that would be a completely different blog post.
     
  7. Tag-scoped Extensions and other changes needed in your iQ setup: Depending on how you have set up your Tealium iQ (TMS) Adobe tracking, you need to change around quite a lot for it to work with UDH. E.g. if you feed your Adobe tag in iQ mostly with data from tag-scoped Extensions, then you have to turn those into “All Tags” Extensions and make sure they don’t destroy any other Extension logic (which is usually the case). Another case is the Success Events mapping which works totally differently from iQ.





Source link