Campaign-specific conversion pixels

[CostPerKill]

Both AdsBridge and TrackingDesk use identical tracking pixels for all campaigns. As a result, if one of my clients puts the pixel on a popular offer landing page, I start seeing conversions in my other campaigns too. Needless to say, it's pretty terrible for my stats. I know my clients should use separate LP urls for me and other traffic sources, but some of them just won't do that and I still want to work with them.

A simple solution would be to fire the pixel with an extra parameter - campaign ID. That way only conversions from users who actually clicked this campaign would be counted.

I know this is pretty standard stuff in affiliate network tracking. I'm not sure why dedicated trackers don't have it.

Any ideas?

 

[CostPerKill]

Here's a rough picture of what's happening:

 

[trackingdesk]

It's a misconception and misunderstanding.

1. User A clicks on TD campaign URL - > catches a cookie -> Signups -> redirect to thank you page -> Image pixel loads on user's browser -> Cookie with unique id is identified on Browser -> TrackingDesk is pinged with conversion
2. User B clicks on offer from a NON TD campaign URL - > signups - Redirected to thank you page - > Image pixel loads on user's browser - > Cookie not found on user's browswer - > TrackingDesk doesn't recognizes the conversion.

The uniqueness is on the click as opposed to the image pixel. You can put 20 image pixels of 20 different TD affiliate accounts and still, only the one that is relevant to the cookie that has generated the click and conversion will load and will be recognized.

The cookie unique ID carries the campaign info - traffic source, keyword, clickid etc... affiliate network, offer id, offer link id and this is what makes it unique.

Let me know if that solves your issue.

ps: this is Trackigndesk - not sure how adsbridge deals with this, but it's fairly standard protocol.

 

[CostPerKill]

Let's assume all 3 urls are in fact TrackingDesk. User John DID click on a TD campaign URL X, but did not complete Offer X. Instead, he forgot all about it, and later found offer Y landing page in some other way (non-TD). TD conversion pixel fired, John had a TD cookie, so a conversion did register... In campaign X.

And this is exactly what's happening to me now, as I run multiple campaigns and some of my advertisers fire my pixels for all users (not just users who come from me). All pixels are identical, they don't distinguish which campaign should be "pinged" - and that's the root of this problem, I think.

I'm not sure how to describe this better.

 

[trackingdesk]

Attribution and conversion is a very sensitive and delicate business. One cannot expect mix all sorts of things in a thank you page and expect "systems" to find the way to the right attribution, source out of thin air.

For tracking and attribution to work there is one rule that must be respected: One platform must be responsible for the attribution. Whatever the platform is - trackingdesk, hasoffers cake, adsbridge... whatever you pick is what will be setting the rules for attributing conversions.

Yet, and this will contradict what I just said Nowadays, advertisers, ecommerce and others, are well aware that a good portion of their conversions are the results of multi channel marketing - display, affiliates, offline, ppc etc... and therefore, they adopt multi-attribution models or call it multi-touch attribution.
They will indeed be able to allocate a single conversion to multiple traffic sources.

And yet, in order to drill down into such model, you still need one single platform to manage your attribution.

Back to our issue - image / client based pixel - is by all account, super easy to setup, but it comes with some down sides, and the one you described is clearly one of them.

Our next release will allow you to add additional parameters to your pixel tracking.

Hope that helped clearing up the matter.

Best regards,
Laurent

 

[trackingdesk]

Let's assume all 3 urls are in fact TrackingDesk. User John DID click on a TD campaign URL X, but did not complete Offer X. Instead, he forgot all about it, and later found offer Y landing page in some other way (non-TD). TD conversion pixel fired, John had a TD cookie, so a conversion did register... In campaign X.

And this is exactly what's happening to me now, as I run multiple campaigns and some of my advertisers fire my pixels for all users (not just users who come from me). All pixels are identical, they don't distinguish which campaign should be "pinged" - and that's the root of this problem, I think.

I'm not sure how to describe this better.

I'm going to complicate the matter a little more:
Let's say you have set pixels for each of the offers you're running.
User Y not completing offer 1 and instead completes offer 2 via an other traffic source - you're not making $
User Y not completing offer 1 after clicking your link, comes back via a retargeting campaign and completes offer 1. Your pixel fires, and the retargeting pixel fires... Who's making money? You? Both? How do you split the $?

As exposed earlier, unless the advertiser has a proper attribution model / platform he will be facing those situations on a regular basis.

 

[trackingdesk]

hi @CostPerKill - I omitted an element.

We provide 3 types of conversions pixels:

• Postback
• Global image (without parameters)
• Image pixel with parameter. In this pixel, you can add the conversion id ({event_id}) that was initially passed with the traffic. Since the user didn't arrive on the conversion page with an event_id, then the pixel will load empty and therefore, the conversion will not load in TD.

If you're advertiser is capable of capturing the {event_id} and adding it to the image pixel, then you're good.

Hope that helps.

 

[CostPerKill]

Thanks for your detailed posts, Laurent.

This issue is not so much a problem for the advertiser, but for me, because it screws with my stats. It's not good when I get conversions in the wrong campaigns, because I can't make any informed decisions about optimization and the like.

I realize it's not a problem when people work with networks (which take care of firing the right pixels at the right time), but I work with most of my advertisers directly, and 90% of them can't or won't implement proper tracking (unique urls etc.).

 

[Alex AdsBridge]

Hello!
I checked the discussion and it seems that the only solution is to use a script (that you could find on the internet). That will check the link and if there is no information about traffic source parameters or any other parameters that were in the campaign, pixel won't fire back the converion from Offer2 to Campaign1. If the user has such parameters in his link, pixel will fire back the conversion to the correct campaign.
Hope this helps!
-Alex

 

[trackingdesk]

Thanks for your detailed posts, Laurent.

This issue is not so much a problem for the advertiser, but for me, because it screws with my stats. It's not good when I get conversions in the wrong campaigns, because I can't make any informed decisions about optimization and the like.

I realize it's not a problem when people work with networks (which take care of firing the right pixels at the right time), but I work with most of my advertisers directly, and 90% of them can't or won't implement proper tracking (unique urls etc.).

Not so much of a problem anymore as we just released offer specific conversion pixels.

Details can be found in our knowledge base Knowledge base | TrackingDesk Knowledge Base

 

[CostPerKill]

Hello!
I checked the discussion and it seems that the only solution is to use a script (that you could find on the internet). That will check the link and if there is no information about traffic source parameters or any other parameters that were in the campaign, pixel won't fire back the converion from Offer2 to Campaign1. If the user has such parameters in his link, pixel will fire back the conversion to the correct campaign.
Hope this helps!
-Alex

Thanks for your input Alex. I see that TrackingDesk has already implemented campaign/offer-specific pixels; maybe it's something you could implement as well.