Structuring your offers

An offer has one currency, one set of partners and one set of commissions, and it is either assigned to one country or available globally. How you split your offers decides how simple tracking, payouts and reporting stay later, so decide it before you build.

Most setups combine two kinds of offers:

• A product offer for each advertiser or product.
• A site offer for a whole website that promotes all of them.

One offer per product

• Assign the real advertiser as the offer’s advertiser.
• The affiliate link goes straight to the advertiser. Their pixel or postback reports the conversion.
• For leads through an iframe or the API, add a pingtree with one channel that uses that advertiser’s integration. No channel filters are needed, the offer already is the advertiser.
• Partners who want to promote one specific brand get this offer.

One offer for a whole site

Use it when the website compares several products and affiliates promote the site, not a single brand.

• Create an internal advertiser for the site itself. Every offer needs a main advertiser, and this keeps the site separate in advertiser reports.
• The affiliate link goes to your website.
• The form on the website sends the lead into the offer’s pingtree. Each channel represents one advertiser, uses that advertiser’s integration and has its own filters that decide which leads it gets.
• Links from the website to advertisers, where there is no form, are affiliate links of the product offers with the owner_id of the affiliate who brought the visitor. The conversion lands on the product offer and the right advertiser, and the affiliate still gets the credit. See Affiliate ID rewrite.
• Several sites can promote the same advertisers. Give each site its own offer and reuse the same integrations as channels in each of them.

Verticals inside one offer

One site often covers several product types.

• Give each vertical its own form structure. Each structure has its own pingtree, and you switch between them in the Pingtree tab.
• Put fields that are the same across verticals into global fields, so integrations map them once.
• Keep verticals in one offer when they share the country, the currency and the partners. Split them into separate offers when they do not.

Countries

You can create one offer per country if the markets differ in currency, advertisers or the data they require, or if you want to report and pay partners separately for each country.

• An offer has one currency, and commissions, transactions, balances and invoices all use it. Markets with different local currencies can share an offer, but every commission in it is paid in that one currency. If you need to pay each market in its own currency, give it its own offer. See Currency.
• An offer is assigned to one country or set as global. A country offer gives you reports by country without extra setup.
• Local markets usually have local advertisers, so the pingtrees differ anyway.
• Affiliates are not affected. The API uses one endpoint for every offer and only the offer ID or structure ID changes. See API integration.
• Structures can be shared between country offers. Create a country-specific structure only where a country needs different fields.

A global offer makes sense when the product itself is global: one currency, advertisers that accept leads from any country, and the country is only an attribute of the lead. Filter on it at the channel where an advertiser needs that.

An advertiser serving several countries can be a channel in each country offer. The integration stays the same, and the commission is in the currency of each offer.

Commissions

• Each commission sets what the advertiser pays and what the affiliate earns.
• On a site offer, create commissions with a condition on the channel, so each advertiser pays its own amount while the affiliate is paid by the rules of the site offer.
• Affiliates never see which channel bought a lead. The site offer can pay affiliates one amount even when advertisers pay different ones.
• On a product offer, the commission needs no channel condition.

Tracking conversions per advertiser

The Tracking API does not belong to an offer. It runs on conversion events, and its conditions decide which ones it handles.

• Set the condition on Advertiser to cover all conversions of one advertiser, from product offers and site pingtrees alike.
• Add a condition on Channel or Integration when one advertiser needs different settings per channel, for example different tokens.
• Use the conversion type Sale or Prospect for conversions reported by pixel or postback after a link, and Send for leads delivered through a pingtree.
• Use the Created trigger for calls to advertisers, so the update that comes back does not start the call again.
• For leads delivered through a pingtree, store the advertiser’s own ID for the lead from their response in the integration. Without it the Tracking API has nothing to ask the advertiser about.

Several advertisers on one delivery tool

A common case: advertisers take leads by email, and every lead goes out through the same mailing tool. The scenario is the same for all of them, only the recipient differs.

• Create one integration per advertiser anyway. An integration belongs to one advertiser, and tracking, commissions and reports follow it. One shared integration would put every lead on the same advertiser, and a Tracking API or commission could not tell them apart.
• Keep the delivery logic in one main scenario and call it from each advertiser’s integration with a SubScenario node. The advertiser’s integration holds only what differs, such as the recipient address. A change to the email is made once in the main scenario and applies to every advertiser.
• Use the same integration everywhere the advertiser appears: as a channel in each site pingtree, where channel filters decide which advertiser gets the lead, and in the advertiser’s own product offer, where no filter is needed.
• Include the send_id in what you deliver and ask the advertiser to return it. There is no external ID to match on, and in a pingtree all channels share the same Origin ID. See Conversion IDs explained.
• Results arrive by postback or import, matched on the send_id. There is nothing for a Tracking API to poll.
• Add a channel filter on lead history if the same person should not reach one advertiser twice through different sites.

Naming

With many advertisers and several sites, the number of integrations, channels and commissions grows quickly. Name them with one pattern so you can filter by any part of the name.

• Integrations: by advertiser, for example mail_providername.
• Channels: by advertiser and site, for example providername_sitename.
• Commissions: the same pattern as the channel they belong to.

Example

Two comparison sites in one country, several verticals, and dozens of providers that take leads by email:

• Integrations: one per provider, each with its own advertiser, all calling the same main email scenario through a SubScenario node.
• Site offers: one per site. Each has a structure and a pingtree per vertical, with every provider as a channel filtered to the leads it accepts.
• Product offers: one per provider, for partners promoting a single brand, using the same integration without filters.
• Commissions: per channel in the site offers, one per product offer.
• Tracking: postbacks or imports matched on send_id, with a Tracking API per advertiser only where the advertiser has a status API.