Application Support:Tracking Settings

From HasOffers

Contents

Click Metrics

Sets default click statistic to be either all clicks (every click on an affiliate tracking link) or unique clicks (by visitor). The click column in reports will be determined by this setting. Affiliates only have access to clicks while employees have access to clicks, gross clicks and unique clicks. Gross clicks are higher than unique clicks by a visitor clicking on tracking link more than once.

Setting click metrics to display unique clicks can cause CPC, RPC, CTR, etc. to be higher than if clicks were set to all clicks since they are generally less unique clicks than all clicks.

Click Display

Allow affiliates to access statistics for only gross (all) clicks, unique clicks or both gross and unique clicks. If set to both gross and unique clicks, affiliates will have both gross clicks and unique clicks in their reports.

Conversion Approval

Feature that can be enabled by offer that requires advertisers or employees to approve conversions before affiliates are credited. Pending conversions are displayed in the Conversion Report and can be approved. For more information refer to Conversion Approval.

Conversion Management

Feature to add and remove leads from statistics by affiliate and offer. Empower selected employees to have permission to Adjust Conversions as well. For more information refer to Adjust Conversions.

Encrypt Tracking Links

Force all affiliate tracking links to be generated encrypted using a hash - tiny / shortened URLs. Note that encrypted tracking links take about one minute to be loaded into the ad server after generating the link.

Encrypt Conversion URLs

Feature that can be enabled by offer to force it's conversion tracking URL to be encrypted. By using this setting the conversion URLs will include an encrypted hash rather than the offer ID. This helps prevent fraud as affiliates can't easily know the URL to record false conversions.

Transaction ID Value

The ad server does not allow conversions with duplicate transaction IDs unless specifically enabled on an offer. Thus, if the a user created a conversion with the Transaction ID of 123456789 and then 10 minutes later completed the offer again and the conversion pixel was displayed with the user has the same Transaction ID set of 123456789, then this second attempt would be a duplicate conversions and won't be recorded.

Below are the three different methods for how the ad servers generate Transactions IDs:

  • Random Number - Each time a user clicks on a tracking link or loads an impression pixel, they are assigned a random number for the value of their Transaction ID. Using Random Number records all conversions from unique sessions (random number as transaction ID). Random Number doesn't provide any protection against duplicate transaction by the same user.
  • IP Address / Date - Each time a user clicks on a tracking link or loads an impression pixel, they are assigned a number comprised of their IP Address and the current date for the value of their Transaction ID. So if a user's IP Address is 123.123.123.123 and today's date is 2010-06-05 then their transaction ID will be 12312312312320100605. Note the the time is actually a unix timestamp and not just the year-month-day. Thus, each time a user with the IP address and same date will get the same transaction ID until its a new day. Thus, this user is only able to create 1 conversion per date. It doesn't take into account if they've created a conversion on another offer already. This setting of IP Address / Date is perfect for Advertisers that have 1 product but use multiple offers for the one offer.
  • IP Address / Date / Offer ID - Each time a user clicks on a tracking link or loads an impression pixel, they are assigned a number comprised of their IP Address, current date, and the ID of the offer the advertisement is for. So if a user's IP Address is 123.123.123.123, today's date is 2010-06-05 and offer ID is 99, then their transaction ID will be 1231231231232010060599. Note the the time is actually a unix timestamp and not just the year-month-day. Thus, each time a user with the same IP address and date can only create one conversion per offer per day. A user can create on conversions on 100 different offers on the same date, just as long as transaction IDs were set on click or impression by 100 advertisements associated with the offers. This setting of IP Address / Date / Offer ID is perfect for Networks that have lots of offers from different advertisers. It limits 1 conversion per user per day per offer and all other conversion attempts with the same Transaction ID will be flagged as a duplicate conversion.

You can further limit duplicate conversions based on a value supplied by the advertiser on conversion. Refer to Limit Conversion by Unique ID

Alphanumeric Transaction IDs

Set up your tracking to generate alphanumeric transaction IDs. Microsoft Excel rounds numbers longer than 10 digits making the transaction ID value wrong. By having the transaction IDs be alphanumeric, the letters in the transaction IDs are rendered as a string and not a number in Microsoft Excel making it easier to export transaction IDs. Verify with your advertisers and other networks before enabling this setting to make sure they accept alphanumeric transaction IDs.

Default Redirect URL

The default redirect URL allows traffic to specify a link to send traffic to in the event that the there are no valid offer URLs to redirect to. Below are the events in which traffic will be directed to the Default Redirect URL:

  • URL is formatted incorrectly missing the affiliate ID or offer ID
  • Offer not found because it was deleted or doesn’t exist
  • Advertiser not found because it was deleted or doesn’t exist
  • Affiliate not found because it was deleted or doesn’t
  • Affiliate doesn’t have approval to run offer
  • Offer is paused and no offer to redirect to
  • Offer is expired and no offer to redirect to
  • Offer has exceeded its lead cap and no offer to redirect to

Global Click Macro

Track all clicks through a third-party system by enabling Click Macro. You can include either {redirect} or {eredirect} in the Click Macro URL to have clicks redirect to the third party system. The redirect variable includes the offer URL not encoded while the eredirect variable includes the Offer URL url encoded. If there is a query string in the click macro URL its recommended to use eredirect. Or omit these redirect parameters and the ad server will do a Server Response to the provided Click Macro URL for each click.

Optional variables can be included in the Global Click Macro URL and will be replaced automatically by the ad servers. These variables for the Global Click Macro are:

  • Redirect Url: Add {redirect} in the Click Macro URL and it will be replaced by the Offer URL for that click.
  • Encoded Redirect Url: Add {eredirect} in the Click Macro URL and it will be replaced by the url-encoded Offer URL for that click.
  • Affiliate ID: Add {affiliate_id} in the Click Macro URL and it will be replaced by the ID of the Affiliate promoting the offer.
  • Affiliate Sub ID: Add {aff_sub} in the Click Macro URL and it will be replaced by the value of Affiliate Sub ID passed in via an affiliate tracking link.
  • Affiliate Source: Add {source} in the Click Macro URL and it will be replaced by the value of Affiliate Source passed in via an affiliate tracking link.
  • Offer ID: Add {offer_id} in the Click Macro URL and it will be replaced by the ID of the Offer.
  • Offer URL ID: Add {$offer_url_id} in the Click Macro URL and it will be replaced by the ID of the Offer URL used.
  • Advertiser ID: Add {advertiser_id} in the Click Macro URL and it will be replaced by the ID of the Advertiser of the offer.
  • Country Code: Add {country_code} in the Click Macro URL and it will be replaced by the user's country code (ISO 2-letter code, i.e. US).
  • Custom Variables: Add {params} in the Click Macro URL if the Custom Variables option above is enabled. {params} will be replaced by the extra variables passed by the Affiliate into the affiliate tracking link.
  • Transaction ID: Add {transaction_id} in the Click Macro URL to send a unique transaction number to the Advertiser. Use this when trying to verify individual leads, to enable cookieless client-based tracking, or when server response tracking is required.
  • Offer Reference ID: Add {offer_ref} in the Click Macro URL and it will be replaced by the Reference ID of the offer.
  • Affiliate Reference ID: Add {affiliate_ref} in the Click Macro URL and it will be replaced by the Reference ID of the Affiliate promoting the offer.
  • Advertiser Reference ID: Add {advertiser_ref} in the Click Macro URL and it will be replaced by the Reference ID of the Advertiser of the offer.

Example Click Macro URL that uses eredirect: http://www.hasdemo.com/clickmacro.php?url={eredirect}

Network Postback URL

Option for networks to enable a network postback URL. This URL will always be called on conversion, and the URL supports dynamic variables. For shared offers both the shared brand and parent brand URLs are called on conversion.

Optional variables can be included in the Network Postback URL and will be replaced automatically by the ad servers. These variables for the Network Postback URL are:

  • {aff_sub} for affiliate sub ID
  • {aff_sub2} for affiliate sub ID 2
  • {aff_sub3} for affiliate sub ID 3
  • {aff_sub4} for affiliate sub ID 4
  • {aff_sub5} for affiliate sub ID 5
  • {adv_sub} for the advertiser sub ID
  • {source} for affiliate source name
  • {payout} for affiliate’s offer payout
  • {offer_id} for the offer ID of the offer
  • {transaction_id} for transaction ID of the record
  • {ran} for a random number
  • {session_ip} The IP address on the click
  • {ip} The IP address on the conversion
  • {goal_id} If the offer has a goal, this is its identifier number
  • {sale_amount} for the amount of the sale
  • {currency} for the offer's currency abbreviated
  • {offer_url_id} The ID value of the offer URL selected
  • {customer_id} With customer lists, this is the value assigned to the customer for that conversion
  • {offer_ref} The reference id value set for the offer
  • {affiliate_ref} The reference id value set for the affiliate
  • {advertiser_ref} The reference id value set for the advertiser of the offer

Traffic Referrals

Tracks and reports the referral web addresses to offers from affiliate tracking links. Data is available in the [[Application_Support:Statistics#View_URL_Referrals|Traffic Referrals] report.

Hide Referrals

You can block advertisers from receiving referral URLs from affiliates by enabling the Hide Referrals setting. Enabling this Hide Referrals features removes the referral URL from affiliates’ traffic before sending it to the advertisers offer.

This function uses a four step approach to remove referral URLs from all affiliate traffic sources.

Step 1

  • First one does a meta refresh to itself.

Step 2

    • If referral blank or set as tracking domain, redirect to offer url.
    • If there is still a referral set, it does a javascript redicect back to itself

Step 3

    • If referral blank or set as tracking domain, redirect to offer url.
    • If there is still a referral set, it does an auto form submit back to itself

Step 4

    • If referral blank or set as tracking domain, redirect to offer url.
    • If there is still a referral set, it goes to a page that says "Click to Continue" which makes the redirect page the referral when the user clicks.

Less than 0.5% (1/2 of a percent or less) make it to the 4th refresh. The redirects are usually cleared with the first two, the third JavaScript clears most remaining.

Offer Whitelisting

Enforce conversion requests to be validated against a list of IP addresses or referrer domains. You can specify IP addresses to be whitelisted for offers that use Postback URLs and domain names for offers that use iFrame or Image pixels. When an IP address is whitelisted, the adservers check against a list of IPs to make sure the IP is authorized for the offer. If the IP address does not match the approved IPs, the conversion is deemed fraudulent and will be rejected. When a referral domain is whitelisted, the ad servers check to make sure the referring URL to the conversion pixel matches a whitelisted URL. The conversion pixel’s referral domain should be the same URL that hosts the pixel. If the referring URL does not match a whitelisted domain, the conversion is deemed fraudulent and will be rejected.

Specify Payout on Click

Allow the payout to be passed in to a tracking link on click. This specified payout amount will override all other payout settings including the default offer payout, any tiered payout for the offer, and any specific affiliate payout for the offer. This should be used for internal tracking as enabling this feature can lead to abuse by affiliates. Append payout= to the end of tracking links followed by the amount.

http://demo.go2jump.org/aff_c?offer_id=1&aff_id=1&payout=5

Specify Amounts on Conversion

Allow the payout and revenue to be passed in on the conversion request. Any specified amounts will override all other payout and revenue settings including the default offer payout, default offer revenue, tiered payout, tiered revenue, specific affiliate payout for the offer, and specific revenue for the offer. Append payout= or revenue= to the end of conversion URLs followed by the amount.

http://demo.go2jump.org/aff_ls?offer_id=1&payout=5&revenue=10

Specify Status on Conversion

Allow the status of conversions to be set in conversion requests. The specified status of a conversion will override the determined status including pending conversion settings or rejecting conversions based on fraud settings. Append status= to the end of conversion URLs followed by approved, pending or rejected. This feature is best used when the advertiser has their own fraud system and wants to report fraudulent conversions as rejected. Or to override the default pending conversion status if the offer has conversion approval enabled.

http://demo.go2jump.org/aff_l?offer_id=1&status=pending

Enforce Conversion Referrals

Requires a referral URL to be set when the conversion pixel is loaded for all offers with cookie based tracking. Conversions with no referral URL will be set to rejected. This is feature helps prevent fraud as only conversions will be approved that have a referral URL to the conversion pixel. This feature only works with offers that use iFrame or Image pixels and does not work with offers that use Server Postback since there isn't a referral URL usually on a server call. If feature is enabled then conversions that don't have a referral URL to the conversion pixel will be recorded with status of rejected and visible in the Conversion Report. Rejected conversions are only visible by employees in the admin interface. Rejected conversions can be approved if you want to credit an affiliate for a conversion.

If disabled, the ad server disregards whether there is a referral URL to the conversion pixel and all conversion will be recorded.

Enforce Conversion Tracking Protocol

Disable multiple conversion tracking protocols per offer and only allow conversions that match the offer's conversion tracking protocol to be approved. If the conversion request is using a different conversion tracking protocol than the one set for theo offer, then the conversion will be set to rejected.

If the conversion is trying to be recorded using the conversion tracking protocol of HTTP iFrame pixel white the offer is set to Server Response with Transaction ID, the conversion will be rejected since the protocols don't match.

Auto Reject Duplicate Conversions

Duplicate conversions are determined by the Transaction ID Value. If feature is enabled then duplicate conversions are recorded with status of rejected and visible in the Conversion Report. Rejected conversions are only visible by employees in the admin interface. This feature is good to see which affiliates are generating duplicate conversions and you can approve rejected conversions if you want to credit an affiliate for a conversion.

If disabled, duplicate conversions are not recorded and won't be included in any reports. They are disregarded and not tracked.

Limit Conversion by Unique ID

Enforce the ad servers to only record a single conversion by unique ID specified in conversion URL. The unique ID could be user ID from the advertiser. Append conversion_unique_id= to the end of conversion URLs followed by the unique ID. This will enforce only 1 conversion per unique ID forever.

If you have a user with the ID of 12345 and you want to record 1 conversion ever on your network for the user, then you could pass in their user ID as the value of conversion_unique_id. The ad servers would first look to see if there is a conversion with the unique ID of 12345; if there is the conversion will be rejected since there is already a conversion recorded for the specified unique ID, else the conversion will be recorded as approved.

http://demo.go2jump.org/aff_l?offer_id=1&conversion_unique_id=12345

If you want to limit conversions on an offer or offer / goal basis, then you would just include the offer ID and/or goal ID with the unique ID value. If you have a user with the ID of 12345 and you want to only allow them to have one approved conversion for offer 9, then append 9 before the user ID and specify it as the value of the conversion_unique_id. If user 12345 already created a conversion for offer 9, he could still create a conversion for offer 7 since the you would supply the conversion_unique_id value of 712345.

http://demo.go2jump.org/aff_l?offer_id=1&conversion_unique_id=912345

You could include in sort of value up to 100 characters long.

Other values to limit conversion by:

Conversions from Proxy

If a conversion was created from a proxy, then in many cases it may be fraudulent. You can set the status of the conversion to pending or rejected for review, when the conversion is detected to be created from a proxy. Proxy information provided by Digital Envoy which is significantly more accurate than other providers. A status message will be associated with the conversion saying it was detected as a proxy. You can view the status message of a conversion associated with a proxy on the Conversion Report.

Maintain Custom Tracking Domains

Set all traffic to remain on custom tracking domain and prevent redirect to offer or global tracking domain. Enabling this feature will require conversion pixels to be placed on each offer for each domain. If the offer users conversion tracking protocols of Server Postback then additional postback URLs will not need to be placed for custom tracking domain.

With this option disabled, a custom tracking domain redirects back to the default tracking domain for the network since the advertiser has only placed the conversion tracking pixel for the default domain.

With maintain custom tracking domains enabled, the user doesn't get redirected to the default tracking domain. This requires the advertiser to have an offer pixel placed for the custom tracking domain as well.

Tracking Mobile App Installs

Track application installs on mobile devices with this cookie less tracking option. Mobile App Postback should only be used to record installs of mobile applications generated from mobile traffic. The Mobile App Postback URL will need to be embedded into the application. [[Application_Support:Mobile_App_Installs_Tracking|Mobile App Install Tracking]

Support Questions

Retrieved from "http://wiki.hasoffers.com/wiki/Application_Support:Tracking_Settings"

 
Email this page to a friend or co-worker