Pixel Tracking Foundations and Troubleshooting Tracking Issues
Foundations – Entity Introduction
...
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:
...
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
...
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.
...
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?
...
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.