Session Regeneration

Session regeneration allows you to use a criteria other than the system default of placing cookies on the user's machine as the basis for counting unique clicks (hence 'session') and also is used for the attribution of a click to a conversion (hence regenerating the session), typically when tracking mobile app installs in conjunction with the CAKE mobile SDK. Session Regeneration allows you to specify a method for regenerating the session; these can involve the IP address, browser User Agent, Device, passed in tracking ID using a Sub ID or a combination of the above. 

Session regeneration, like cookie days, is unique to the offer and applies to all campaigns for that offer. The setting can be found on the Offer card > Attribution tab.

Here you will find a drop-down of the various types of session regeneration that you can choose. You can choose one data field like IP address or a Sub ID field (s2-s5 only as s1 is dedicated to SubAffiliate ID's) or you can select a combination of data fields.

Under most Session Regeneration Types, the session regeneration duration (ie the lookback window) has a maximum setting of 1 day (86400 seconds). This means that all clicks with the same information for the selected session regeneration type will be tracked by CAKE as the same click. If you regenerate the session using only a Sub ID, the maximum lookback window increases to 30 days (2,592,000 seconds). See section below for further information on this.

For example: if you select IP only and 86,400 seconds, all clicks from the same IP within one day will be counted as the same click.  Duplicate clicks will be tracked both in your admin click report as well as the Affiliate Portal click report by clicking on the number of clicks in the far right column.

When tracking mobile app installs, session regeneration is used because cookies are not shared between a mobile browser and the App Store, and when a user goes through the App Store we lose the ability to track the request ID that CAKE usually requires with cookie-less tracking. However, there are common data points that can be tracked between the click and the app launch, such as IP, Apple Identifier for Advertisers (IDFA) and Google/Android Advertising ID (GAID / AAID), that helps us to link the conversion to the click and the traffic source that generated the install conversion.

When you are using a custom session regen type to track conversions like this, you will need to modify your pixel as well so that we can use that value to tie the conversion back to the click.

IP Only: Unless you're using a postback, we will record the user's IP on the click and the conversion so we will match the IPs together with no other parameters added:

<iframe src="http://trackingurl.com/p.ashx?o=123456&t=TRANSACTION_ID" height="1" width="1" frameborder="0"></iframe>

When the postback is coming from your own server and not the user's device, the postback calls will all be coming from your server IP and not the user's IP, so you will need to pass back the user's IP in the pixel like this:

http://trackingurl.com/p.ashx?f=pb&o=123456&ip=123.45.6.78&t=TRANSACTION_ID

Unique Key (s2-s5): You must modify your pixel to pass CAKE the subID field that you're using as your session regeneration type. Regardless of which subID field (s2-s5) you are passing the value into, you will use the k (key) parameter in your pixel like this:

http://trackingurl.com/p.ashx?f=pb&o=123456&k=UNIQUE_KEY&t=TRANSACTION_ID

CAKE will take this value and look back through all the clicks within the Session Regeneration Seconds to look for a matching value. In the case where only a SubID is being checked, this is a maximum of 30 days, otherwise the maximum lookback window is 24 hours.