Affiliate new customer tracking should use your purchase records and a written eligibility rule to decide whether an order qualifies for a first-purchase commission rate. A new browser session, account registration or affiliate click does not establish that someone is a new buyer. When purchase history is incomplete, use an explicit exception process rather than silently classifying the customer as new.
This approach suits advertisers that distinguish acquisition orders from repeat purchases. Awin provides the implementation examples below, but the proposed review process also helps teams assess other affiliate platforms. Confirm equivalent fields and rule behaviour before applying it elsewhere.
1. Define what counts as a new customer
Start with a sentence that a publisher, developer and campaign manager can interpret the same way. For example: a qualifying new customer has no earlier qualifying purchase in the advertiser's available customer history when the current order is accepted. This is a proposed definition, not a platform requirement.
Then resolve its boundaries. Does the programme cover one storefront or several brands? Do earlier app purchases count? Does a cancelled first order establish purchase history? Is an account with an unpaid order still eligible? Record the answers before configuring rates.
Separate three questions: whether the customer qualifies as new, which partner receives attribution, and whether the order qualifies for commission. A valid first purchase can still require order validation. Likewise, a returning customer can place a valid, attributable order without qualifying for an acquisition rate.
Keep that final order review connected to your affiliate conversion reconciliation process. Customer classification should not bypass checks for returns or cancellations.
Assign one business owner to the definition. Engineers should implement an agreed rule rather than infer commercial intent from a field named "new customer".
2. Choose purchase history rather than visit history
Google Analytics defines new users through first-visit or first-open events. Its returning-user metric concerns previous sessions. Those definitions describe website or app usage, not whether an order is someone's first purchase. See Google's GA4 user metrics documentation.
For commission eligibility, use an agreed customer reference and qualifying order history in your commerce or customer system. Decide how guest checkout joins that history and what happens when records cannot be matched confidently. A fresh account alone should not override an identified earlier purchase under a purchase-based definition.
The following table proposes review outcomes. It is an operating framework to adapt, not a claim about automatic platform behaviour.
| Situation at order acceptance | Proposed classification approach | Practical action |
|---|---|---|
| Recognised customer with an earlier qualifying purchase | Returning | Apply the documented returning-customer rule |
| Recognised customer with complete relevant history and no earlier qualifying purchase | New | Record the evidence supporting first-purchase eligibility |
| Guest order with an unresolved customer match | Unknown | Follow the agreed exception or fallback process |
| Customer history unavailable during checkout | Unknown | Recover classification through a supported workflow |
| Earlier purchase exists in another included storefront | Returning | Apply the programme's stated storefront scope |
Unknown is an internal evidence state, not permission to invent a network parameter value. Your integration must translate it into a supported, documented outcome. If the platform cannot support your intended review process, simplify the commission arrangement until it can.
3. Separate acquisition reporting from commission configuration
Awin documents an additional customer acquisition parameter for reporting, with the values NEW and RETURNING. It provides guidance for conversion tags, fallback pixels and server-to-server tracking. That field communicates customer type; do not assume that adding it alone creates the intended commission arrangement. See Awin's customer acquisition documentation.
A separate Awin developer guide describes commission groups for new and existing customers, using NEW and EXISTING in its group example. It also warns that tracked commission group codes are sensitive to spelling and case, with mismatches receiving the default rate. Read the commission group tracking documentation when mapping your integration.
The different vocabulary matters. RETURNING in the reporting field and EXISTING in the documented group example should not become one casually reused value. Maintain a mapping that states the internal classification, outgoing reporting value and applicable commission group.
Generate these outputs from the same classification decision. Otherwise, the acquisition report might describe an order as returning while the commission configuration treats it as new. Give the campaign team a way to inspect both outcomes against the order reference without exposing raw customer records to publishers.
4. Check the rule that actually determines payment
A correct customer classification can still produce an unexpected commission if another rule takes precedence.
Awin's current Commission Groups help page is explicitly scoped to Awin Classic. It describes sequential condition matching, where the first matching group stops the search, and a default group for unmatched transactions. Check your platform version and plan before relying on those controls.
Review broad rules alongside specific acquisition rules. If both can match an order, test which one wins. Also inspect negotiated partner arrangements. Awin distinguishes transaction-based commission groups from partner-specific rate overrides in its Commission Manager documentation.
Create a small review sheet showing customer classification, matched group, partner override if applicable, and expected commission treatment. Include an ordinary publisher and a publisher with a bespoke arrangement. Do not assume the same order classification produces the same final rate for both.
Treat a rate change as a partner communication task as well as a technical release. Check the platform's current notice requirements, publish a clear eligibility definition, and state when the change takes effect. Avoid promising a first-purchase rate that your available history cannot reliably support.
5. Test ambiguous orders and common mistakes
Test the rule with controlled customer histories before live acquisition rates depend on it. Include a genuine first purchase, a repeat purchase, guest checkout, an earlier cancelled order and an unavailable history service. Add purchases across included storefronts if the programme definition requires them.
Two closely timed orders deserve a specific test. Decide how the business orders them and which one may qualify as the first purchase. A delayed history update should not accidentally make both orders eligible. Ask engineering to demonstrate the chosen behaviour rather than judging it from two successful tracking requests.
Also test a conversion retry. The same order should retain an explainable classification when resent. Preserve the original decision and any later correction so that a reviewer can distinguish a retry from a new purchase. Add these cases to your affiliate campaign tracking tests.
Common mistakes include treating "not found" as proof of newness when a lookup failed, using account creation date as purchase history, and checking the acquisition report without checking the applied rate. Another is changing the definition after publishers have already delivered orders. Version the rule and retain its effective date so historic decisions remain understandable.
Finally, first-purchase attribution does not establish incrementality. It identifies an attributed order that meets your new-customer definition. Whether the customer would have bought without the affiliate is a separate measurement question.
6. Use a release checklist and review exceptions
Before launch, complete this practical checklist:
- Write the qualifying-purchase definition, including cancellations and storefront scope.
- Identify the customer reference and history source used for classification.
- Define what happens when identity or purchase history is uncertain.
- Map internal classifications to supported reporting fields and commission rules.
- Test default behaviour, overlapping rules and partner-specific overrides.
- Verify repeat orders, closely timed purchases and conversion retries.
- Record the rule version, effective date and exception owner.
- Give publishers a plain explanation of eligibility and the review process.
After release, review unknown classifications and unexpected default-group assignments separately from confirmed new-customer orders. A sudden change in the reported acquisition mix should prompt a check of history availability and field mapping before the team credits campaign performance.
The next step is to trace a small, deliberately varied set of orders from purchase history through classification to the applied commission. Resolve unexplained differences before expanding the arrangement to more partners.
India
UAE
KSA
USA
UK
Canada
Oman
Kuwait
Australia
Thailand