Pixel Tracking Foundations and Troubleshooting Tracking Issues

Foundations – Entity Introduction

In basic pixel tracking, you will ALWAYS have 4 entities:

The Advertiser

The party that is selling the product and that we are hooked into. For example, Wellco Media for Doc Socks, Strong Current Enterpri ses for LiveWave, etc.

- For technical purposes, this can be defined as the advertiser tracking platform, their CRM, or the actual site itself

The Network

This is US – our Everflow, basically. Verve or Kainero regardless.
We use a Network Tracking Platform, and primarily client tracking (javascript/iframe/tag container).

The Affiliate/Traffic Source

The person running the traffic; this can either be a tracking platform (i.e. Voluum, Funnelflux), an ad platform (i.e. Facebook, Google), or a tag manager (GTM, custom, etc.)

If the affiliate is using postback tracking, they will be using their own tracking platform, now defined as affiliate tracking platform

If the affiliate is using javascript/iFrame/Tag Container tracking (now defined as CLIENT TRACKING), they will be using an ad platform, now defined as affiliate ad platform

An affiliate can use both postback and client tracking.

The Customer

The person's whose activity we are trying to track; i.e. the person buying the product. The customer for the purposes of tracking can be defined in two ways:

A Session/ClickID – for postback tracking only, this is an alphanumeric ID generated by EACH tracking platform in the customer flow
A Cookie – for iFrame/Javascript tracking only, this is a cookie/session placed on the customer upon click a link from EACH tracking platform/ad platform, where the information is passed from page-to-page in the browser the customer is using to purchase the product

The Browser

This is the optional 5^th entity, only coming into play during client tracking. The browser hosts the iFrame/Javascript tracking pixels

Foundations – Types of Platforms

There are only really three types of platforms:

Tracking Platforms

These can be owned by the Affiliate, the Network, and/or the Advertiser. These are traffic management tools that generate tracking links, to be used for either of the two major tracking methodologies to be explored in Section III – Foundations, Tracking Methodologies.
The Network will host the Advertiser Tracking Link (or offer URL, if Advertiser Tracking URL doesn't exist)
The Affiliate will host the Network Tracking Link

Ad Platforms

These are owned by the Affiliate only and are how affiliates run ads. This can be Facebook, Google, Yahoo, and everything in between. The Ad Platforms will host either the Affiliate's Tracking Link (if the affiliate is using a Tracking Platform), or the Network's Tracking Link

Tag Managers

These are tags that have a back-end UI that pushes code through them. The most common industry example is Google Tag Manager, but in effect iFrame/Javascript pixels act as tag managers – because they load other code
The Affiliate, the Network, and the Advertiser can all use some combination of tag managers. In general, we don't worry about anything except the Network Tag Manager

Foundations – Tracking Methodologies, and Common Troubleshooting

There are three type of foundational tracking methodologies, each of which defines how we troubleshoot issues

Postback (also known as "Server to Server/S2S") Tracking

This is tracking that ignores the customer's browser entirely, with the customer now being defined purely by session/click generated from the parent page. Because this type of tracking ignores the client/browser, client-based tracking is not possible via platform. There MUST be a tracking link for every postback placed along the customer flow.

To illustrate the basic concept as it occurs in our context, most the time:

The most important parts of this are:

Each entity is functionally independent – if the affiliate is using postbacks, but the network is using client-tracking, then the network can still host iFrame/Javascript, but the Affiliate Platform cannot, and so forth
The customer MUST click a tracking link to generate a session ID. If the affiliate is using postback tracking, the customer must click the Affiliate Tracking Link. If the Network is using postback tracking, the customer must click the Network Tracking Link. This means that Direct linking is not possible for each respective entity, unless the condition of "clicking the tracking link" is met

- Example 1 – Affiliate uses their own tracking link, and the customer ALWAYS clicks it in order to visit an offer. We fire our click pixel on the page, taking the Affiliate Session ID. This is fine for postback tracking.
- Example 2 – Best example of this is "E-Gear Media", where they use their own click pixel. Because the customer does not click the Affiliate Tracking Link (it doesn't exist), they CANNOT use postback tracking, because the pixel has no way of identifying the session
Because in postbacks, the pixel is fired on the server level, ignoring the client/browser – you cannot piggyback iFrame/Javascript pixels via postback tracking. This is why an affiliate will place a postback and iFrame/Javascript separately.

To illustrate a more detailed flow using our predefined Entities:

In general – postbacks are considered the most accurate form of tracking, because they do not rely on the client/browser working 100% of the time. However – they are not wildly used, because they always require a tracking link, and they do not collect as much data as the browser/client provides.
Remember – they also can't piggyback javascript/iFrame pixels, which are the primary tracking method of Ad Platforms.

iFrame/Javascript/img Tracking (also known as "Client/Browser-side") Tracking

Client-side tracking differs from postback tracking in one major facet – it relies on Entity 5, Browser/Client. This means that the cookie is the primary tracking requirement, vs. the session in postback tracking.
Because client-side tracking involves all 5 entities, postback tracking is possible to piggyback via this method

To illustrate in the same format as postbacks (non-direct linking):

Therefore at any time, we can have a maximum of 3 different cookies, with the most significant being the Advertiser, followed by the Network, followed by the Affiliate. If the Advertiser cookie/session is dropped, the Network pixel won't fire, and neither will the Affiliate. If the Network pixel session is dropped, the Advertiser will still fire, but the Affiliate won't, and so forth. This is the CASCADING hierarchy.
When can a cookie/session drop?

The cookie was never placed in the first place
The cookie/session was wiped along the path
The customer is using an AdBlocker, or the browser has 3^rd party cookies disable by default

This is why even when everything is humming along perfect, Point 3 illustrates why Client/Browser Tracking is imperfect. A portion of browsers will have adblocker/cookies disabled. This however is rare – and typically occurs on, at most, 5% of all sessions. For testing purposes, it is unlikely that there is a major issue

The more detailed diagram:

In short - in some ways, on the front of it, tracking via client-side seems easier than tracking via postbacks - because you don't need to worry about the session, the session is handled for you.

However - troubleshooting is many magnitudes harder despite that. To be covered in Troubleshooting documentation.