Adobe DTM vs Tags Comparison: Deploying multiple media pixels with Tags (formerly Adobe Launch)

Recently during a DTM to Launch migration engagement I found a very interesting scenario I think marketers should be aware of. When using Tags (formerly Adobe Launch), if you are running many digital marketing campaigns and have a large amount of 3^rd party media pixels implemented on your site, there is a slight chance you might run into a very specific edge-case scenario that I call “the multi-ID pixel issue”.

Whenever there are two different pixel IDs (for the same vendor) used on the same page, but they should both collect different events, you will see they end up capturing the same events.

In other words, a media pixel is recording events it should not. An example use case is the following:

• Have one global PageView Facebook pixel ID that fires on every page
• Have another Facebook with different pixel ID that tracks a click event-based interaction, like AddToCart

Using a scenario to illustrate:

In this situation, with Tags, both pixel IDs will record the later event (AddToCart) on the click. When using DTM it would not record an AddToCart twice. So why with Launch does it record twice?

Why does it happen in Launch but not DTM?

There are two main reasons this happens: 1) how Tags is designed differently from DTM, and 2) how media pixel libraries are designed.

1) Regarding Tags:

The technical reason why this conflict happens in Launch and not in DTM is the following:

• In DTM, when using non-sequential HTML, DTM will inject the pixels within a hidden iframe. For more information check: https://docs.adobe.com/content/help/en/dtm/using/resources/load-order.html
• Launch does not have non-sequential HTML because everything is either embedded within Launch library or loaded from the Adobe server and added using Postscript, therefore no iframe. For more information: https://experienceleaguecommunities.adobe.com/t5/Adobe-Experience-Platform-Launch/Load-Order-for-Rules-DTM-vs-Launch/qaq-p/293703

2) Regarding media pixels:

In general, 3^rd party vendors design their tracking codes to use a global JavaScript library that needs to be loaded first with the respective pixel ID, and then implement individual “event snippets”. These snippets are the ones responsible for collecting data for the 3rd party, such as page views or add to carts. Event snippets send data to their respective account (pixel ID) because of the global library that initialized first.

In DTM, users tended to implement pixels using non-sequential HTML. This means pixels were deployed within their own iframes. The issue of a “global Facebook pageview tag” capturing the Facebook event of another click tag on the same page did not happen because the Facebook pixel ID from the global library was, in effect, isolated from the Facebook pixel ID used to track the click event.

The difference between DTM vs Launch above means that in Launch there is no iframe and therefore libraries are shared. This results in a conflict, where events tracked for one pixel ID are also picked up by any other pixel IDs that may be implemented the same page.

Solving the issue

We try to recommend using one pixel ID per vendor on a site, in part, for this reason. However, I know it’s not always possible to do so. So we experimented to find out which vendors this conflict happens to, and researched if they have specific instructions on how to overcome:

• Facebook: Conflict is confirmed to yes happen. Solve by sending events selectively to specific pixel IDs on the same page using the trackSingle() function. Follow these advanced implementation instructions
• Twitter: Conflict is confirmed to yes happen. No currently known documentation on how to overcome, but here are Advanced Conversion Tracking instructions
• Google DoubleClick: Conflict is confirmed to not happen. This is because each event requires the pixel ID to be sent with it
• Google AdWords: Conflict not confirmed whether it happens, although must likely not because each event sends the pixel ID with it
• Bing: Conflict not confirmed whether it happens. It could happen but there are no known instructions for how to solve but here is more information on tracking custom events with UET

Aside from solving it through advanced implementation tricks, a DTM to Launch migration could be the perfect opportunity to re-evaluate the need for multiple pixel IDs on one site. I have come to understand that organizations have this set-up mainly because it is a way to separate different teams/agencies costs. It’s difficult to argue against that, but I would look at using custom variables to do that grouping. With some smart planning on how to best structure your digital marketing accounts, I am positive there is a way to keep a single pixel ID and costs grouped appropriately. Another approach would be to welcome the additional events across multiple accounts, you never know if it could come in handy in at one point!