Skip to content

Browser and Registration Attribution

Brand-page link

Any normal terminal page can carry attribution query values:

https://trade.example.com/en/register?affiliate=AFF1024&campaign=FB_CY_01&utm_source=facebook&utm_medium=affiliate&sub_id=creative-7

Supported values are:

  • affiliate
  • campaign
  • link
  • utm_source, utm_medium, utm_campaign, utm_content, utm_term
  • sub_id, sub_id2, sub_id3

The server resolves the brand from the request host. Known, active codes are stored with a server-generated touch id. The request IP is hashed with the brand and is not stored as plain text.

When the browser later calls POST /customer/registration, no marketing values need to be copied by the frontend. The server matches the latest non-expired browser touch.

External landing page

An affiliate can host its own public landing page. It uses the common registration endpoint and passes public attribution values in attribution; no affiliate token is required.

{
  "email": "[email protected]",
  "password": "strong-password",
  "first_name": "John",
  "attribution": {
    "affiliate": "AFF1024",
    "campaign": "FB_CY_01",
    "utm_source": "partner-landing",
    "utm_medium": "affiliate",
    "sub_id": "creative-7"
  }
}

The request must be sent to the relevant brand host. A supplied code is persisted only when it is active and valid in that brand.

Resolution priority

  1. Explicit attribution in the registration request.
  2. installation_id previously bound by /app/activate.
  3. Latest non-expired browser fingerprint touch.

Attribution is snapshotted when the customer is created. Later campaign edits do not rewrite historical customer attribution.