Passing Optional Parameters to Pass Information Cross-Platform

In performance advertising the name of the game is to adapt to the needs and wants of the consumer as quickly and effectively as possible. Doing so requires collecting copious amounts of data points which through analysis provide feedback on how one’s advertising campaign is performing.

Sounds simple enough, but in practice it is easier said than done. This is mainly due to the fact that one’s advertising efforts are generally widespread and thus require working with multiple publishing partners and affiliates simultaneously.

Maintaining a broad network of publishing partners and affiliates allows you to cover the breadth of the advertising market as well as access more channels through which you can collect valuable user data.

On the flip side of this coin, however, is that with all of these advertising channels comes the task of passing information between various platforms with differing systems of identification and naming protocols for parameters, all the while ensuring that the informational value itself remains constant.

Luckily you can do precisely that using the optional variables built into the both the HasOffers and MobileAppTracking platforms. The HasOffers platform supports a wide variety of parameters that you can use in your tracking links and server postbacks to pass information between your system and that of your publishing partners. While some parameters are automatically appended, others are optional and the platform gives you the ability to pick and choose which additional parameters you want to append depending on the values you (or your publishing partners) want passed.

Parameter Variables & Macros

The passing of values between your own internal system, the HasOffers and MobileAppTracking platforms, and your publishing partners’ internal systems requires discerning your “parameter variables” from your “macros” and how to use these two pieces of information appropriately.

Both of these terms have various meanings throughout the tech world and as we do not want to create confusion let’s define now how we at HasOffers use these two terms and their application.

  • Parameter Variable: An attribute in your system that denotes a particular type of variable to be defined; e.g. the ID of a user or some other definitive characteristic of your data.
  • Macro: The value of the parameter it is paired with; can either contain an actual value (e.g. =12345) or can be a placeholder for the value of the parameter (e.g. ={number}) to be dynamically replaced later.

Take the following URL as an example:{network}&sub_site={placement}&sub_ad={creative}&sub_keyword={keyword}

After the “?” you can see that a good many parameters have been appended to the URL; e.g. &publisher_id=587 and &sub_ad={creative}. Parameters - otherwise known as variable-value pairs - are comprised of a parameter variable (e.g. &publisher_id) and a macro (e.g. =587). Thus, a parameter is simply indicating that the parameter variable equals a macro/value.

Placeholder Macros

In the above URL example, the values for some of the macros have already been provided (e.g. &publisher_id=587) while others have the placeholder macro (e.g. &sub_keyword={keyword}). Placeholder macros enable you to essentially request information from an outside source for an internal parameter you are interested in collecting data on.

For example, you want to collect the keyword that triggered your ad. To collect this piece of information, you would append the appropriate parameter - i.e. sub_keyword - along with the placeholder macro that corresponds to that parameter - i.e. {keyword}. On click of the URL, the keyword that triggered your ad would then dynamically replace the {keyword} placeholder macro (&sub_keyword=hasoffers) and you could later view the collected keyword in your reports.

Information In vs. Information Out

Figure 1. The passing of data between your own internal system and a third party affiliate system through the HasOffers system. All data passes through the HasOffers platform and thus ensures consistency of value naming conventions across systems.

We have discussed that a parameter is a variable that you want defined and a macro is the corresponding value for that parameter variable. So, what does this mean as regards appending parameters to your tracking links and postback URLs?

Essentially, it all boils down to the nature of the information being passed; i.e. either into your system or out of your system. Knowing the trajectory of the information is particularly important as this will determine the format of the information required. Therefore when appending optional parameters first consider who needs what information; i.e. are you requesting information or you passing information to others?

Third-party Systems

If you are working with publishing partners and/or affiliates it is imperative that the integrity of the information being passed between everyone’s platforms remains constant and thus transparent. This is best achieved by maintaining open lines of communication with your publishing partners and/or affiliates to ensure that everyone is aware of which parameters and macros are supported by each system and subsequently what information is, in fact, being passed back and forth.

Obviously each third party system you interact with will have its own set of parameters and macros regardless of the fact that the same information is being represented in each system. Thus one of your priorities should be syncing with your collaborative third party systems to understand which values they want passed back to them; i.e. what parameter variable you need to append to your pixels and postback URLs.

Let’s look at an example of this in play. A common practice is for affiliates to pass in their unique session ID on the click through the aff_sub parameter.

Figure 2. The flow of information between your own internal system, the HasOffers system and a third party affiliate system. Parameters and macros used are examples and do not necessarily represent true HasOffers' parameters/macros.

So the affiliate will pass in the unique session id to their offer tracking link like this:

As they are passing this value to you unrequested, it is safe to assume that they are doing so because they would like this value passed back to them in the postback URL.

Therefore, you will want to append the aff_sub parameter to the postback URL like this:{aff_sub}

which the HasOffers system will replace with the corresponding aff_sub value

HasOffers Platform Parameters

HasOffers supports many of the possible macros that can be passed back to the affiliate to maintain a highly transparent transaction between you and the affiliate’s tracking system. The macros used are always contained between curly brackets "{}" and include underscores. Here is the complete list of macros that HasOffers currently supports:

Macro Description
{advertiser_id} ID of advertiser
{advertiser_ref} Reference ID for advertiser
{adv_sub} Advertiser sub specified in the conversion pixel / URL
{aff_sub} Affiliate sub specified in the tracking link
{aff_sub2} Affiliate sub 2 specified in the tracking link
{aff_sub3} Affiliate sub 3 specified in the tracking link
{aff_sub4} Affiliate sub 4 specified in the tracking link
{aff_sub5} Affiliate sub 5 specified in the tracking link
{affiliate_id} ID of affiliate
{affiliate_name} Company name of affiliate
{affiliate_ref} Reference ID for affiliate
{currency} 3 digit currency abbreviated
{date} Current date of conversion formatted as YYYY-MM-DD
{datetime} Current date and time of conversion formatted as YYYY-MM-DD HH:MM:SS
{device_id} For mobile app tracking, the ID of the user's mobile device
{file_name} Name of creative file for offer
{goal_id} ID of goal for offer
{ip} IP address that made the conversion request
{payout} Amount paid to affiliate for conversion
{offer_file_id} ID of creative file for offer
{offer_id} ID of offer
{offer_name} Name of offer
{offer_ref} Reference ID for offer
{offer_url_id} ID of offer URL for offer
{ran} Randomly generated number
{sale_amount} Sale amount generated for advertiser from conversion
{session_ip} IP address that started the tracking session
{source} Source value specified in the tracking link
{time} Current time of conversion formatted as HH:MM:SS
{transaction_id} ID of the transaction for your network. Don't get confused with an ID an affiliate passes into aff_sub

Mobile Tracking Parameters

If you are an Enterprise client, you also have the option to include mobile tracking parameters in your affiliate postbacks. Keep in mind that these can only be passed back using an offer post back URL as no offer pixels will pass these on:

Macro Description
{google_aid} The Google advertiser ID
{android_id} The ANDROID ID for Android devices only. The value should be formatted as lower case. More Info
{android_id_md5} The Android ID of the Android device hashed with MD5 algorithm
{android_id_sha1} The Android ID of the Android device hashed with SHA1 algorithm
{device_brand} The brand name of the mobile device (example: Apple)
{device_id} The DEVICE ID of the Android device iOS UDID is deprecated as of May 1, 2013.See the UDID Deprecation Plan for further details
{device_id_md5} The DEVICE ID of the Android device hashed with MD5 algorithm. The value should be generated based on the original value lower case. md5(aaaaaaaa1111111)
{device_id_sha1} The DEVICE ID of the Android device hashed with SHA1 algorithm. The value should be generated based on the original value lower case. sha1(aaaaaaaa1111111)
{device_model} Model of the mobile device (example: iPhone)
{device_os} operating system of the device (example: iOS)
{device_os_version} The numerical version of the device operating system (example: 4.3.2)
{ios_ifa} Apple’s advertiser identifier with iOS 6+. More Info
{ios_ifa_md5} The IFA ID of the iOS device hashed with MD5 algorithm
{ios_ifa_sha1} The IFA of the iOS device hashed with SHA1 algorithm
{ios_ifv} Apple’s vendor identifier with iOS 6+
{mac_address} The MAC address of the phone’s wifi adapter formatted as upper case with colons. AA:BB:CC:DD:EE:FF
{mac_address_md5} The MAC address of the phone’s wifi adapter hashed with MD5 algorithm. The value should be generated based on uppercase characters with : separating colons. md5(AA:BB:CC:DD:EE:FF)
{mac_address_sha1} The MAC address of the phone’s wifi adapter hashed with Sha1 algorithm
{odin} The ODIN of the device which is the the MAC address of the phone's wifi adapter in a binary array and then hashed with SHA1 algorithm
{open_udid} The OpenUDID of the device
{unid} The unid is not a specific device identifier, but a catch all for all of the above unique identifiers
{user_id} ID generated by app developer (advertiser) that is the same ID of the user in their system
Have more questions? Submit a request


Please sign in to leave a comment.
Powered by Zendesk