Introduction
The restrictions on third‑party cookies force affiliate networks to rethink tracking. For merchants and partners: losing conversion visibility means losing revenue and trust. Affilentra offers in its self‑hosted editions a pragmatic way to close tracking gaps: identity stitching based on first‑party identifiers combined with server‑side reconciliation. This article explains how to configure and operate Affilentra so that clicks, leads and sales can be reliably attributed even without third‑party cookies.
Principles: What Identity Stitching Must Deliver
- First‑party identifiers: Capture of data controlled by the merchant itself (e.g., hashed email, persistent server‑side link IDs).
- Server‑side reconciliation: Merging of events (click, lead, sale) on the server level instead of relying solely on client cookies.
- Separation of roles and transparency: Merchants retain control over products, terms and raw data; partners see their link IDs and payout history.
Preparations in Affilentra (self‑hosted)
Before you begin implementation, check your Affilentra installation for the following points:
- Edition: PRO or NETWORK installed and activated.
- Roles: Software operator, merchant and partner are created and permissions are cleanly separated.
- Webhook configuration: System access to webhook endpoints is available (HTTPS, valid certificate).
- Data protection notices: Consent mechanisms for first‑party data are present and documented.
Step‑by‑Step Configuration
1) Generation and Persistence of Server‑Side Link IDs
Workflow:
- Partner links point to an Affilentra redirect URL. On click, Affilentra generates a unique, persistently stored link_id (UUID or comparable) and forwards it as a query parameter to the merchant URL.
- Affilentra stores link_id, partner ID, destination URL, timestamp and optional client context meta (e.g., campaign tag).
Configuration note: Ensure in Affilentra that link_id is stored long‑term and not tied to browser session cookies. The link_id is the primary identifier for later reconciliation.
2) Capture of Hashed Emails as First‑Party Identifier
When users enter an email at the merchant (e.g., lead, registration, purchase), the merchant should normalize the address before transmitting to Affilentra (trim, lowercase), salt and hash it (e.g., HMAC‑SHA256). Affilentra stores the hash as first_party_email_hash.
Benefit: No plaintext transport, preservation of a stable identifier that can be used across devices once the user provides their email.
3) Server‑Side Postback for Conversions
The merchant sends conversions server-side to Affilentra (instead of sole client pixels). The minimal payload contains:
- link_id (if available)
- first_party_email_hash (if available)
- order_id / transaction_id
- amount, currency
- timestamp
- signature (HMAC, for verification)
In Affilentra you must configure a postback endpoint under Settings → Integrations and store an HMAC shared secret.
Webhook Examples and Flow for Reconciliation
Below is a simplified example of how a merchant server posts a conversion to Affilentra and how Affilentra performs the attribution.
Example Payload (POST)
- partner_id: 12345
- link_id: abcd‑ef01‑... (optional)
- first_party_email_hash: 9f86d081884c7... (optional)
- order_id: ORD‑2026‑0001
- amount: 99.90
- currency: EUR
- timestamp: 2026‑10‑24T12:34:56Z
- signature: HMAC_SHA256(payload, shared_secret)
Reconciliation Logic (Affilentra Side)
- 1. Verify the signature; on failure: return 401 and log the event.
- 2. Search for link_id → direct attribution to partner/click → mark conversion as attributed.
- 3. If no link_id: search for first_party_email_hash → if it matches an existing lead/partner mapping, establish attribution.
- 4. If still no match: fallback matching using order_id/transaction_id against order data or manual review.
- 5. Store the result in the Affilentra DB; notify partner via webhook or callback.
Recommended Webhook Behavior on Merchant Systems
- Implement retry mechanisms (exponential backoff) for transient errors.
- Log all sent payloads with order ID and status for audits.
- Secure webhook calls with HMAC; establish a rotation strategy for secrets.
Fallback Identifiers: Prioritization and Recommendations
In cookieless environments you need a clear prioritization of identifiers. Recommended order:
- Persistent server-side link_id (best reliability for click→sale mapping).
- Hashed first-party email (stable across devices once the user provides an email).
- Order or transaction ID (unique reference, reliable for revenue allocation, less so for attribution).
- Server-side fingerprints (IP + user agent + timestamp hashed) only as a last resort and subject to privacy review.
Important: Document the prioritization in your partner agreement and in Affilentra settings so merchants and partners can trace decisions.
Examples of Common Implementation Questions
How do I handle returning users without an email?
Rely on the server-side link_id that is generated at click and stored in your backend. When the user later converts, the merchant backend compares the link_id values referenced on the order and sends them to Affilentra.
What to do in case of multiple attribution (e.g. multiple clicks)?
Define a clear attribution strategy in Affilentra (server-side last-click or time-decay) and implement this logic in the reconciliation pipeline. Document how link_id priority interacts with email matches.
Security and Data Protection
- Hashing: Use secure HMAC methods with a merchant-side salt that is not stored in Affilentra in plaintext.
- Data minimization: Transmit only the hash, not the email in plaintext.
- Consent: Ensure that the processing of first-party identifiers is legally covered (consent management).
Practical Example: Process in 6 Steps
- Partner link is clicked → Affilentra generates a link_id and redirects to the merchant with the link_id in the URL.
- Merchant stores the link_id server-side on the session/order.
- User purchases / registers → Merchant normalizes and hashes the email, creates an order_id.
- Merchant sends a server-side POST to Affilentra with link_id, first_party_email_hash, order_id and HMAC.
- Affilentra verifies, reconciles (link_id → email → order_id) and marks the conversion; partner is notified.
- Billing and payout are carried out transparently based on the conversion data stored and verified in Affilentra.
Conclusion and Next Step
Cookieless tracking requires a server-side mindset: generate persistent link IDs, use hashed first-party emails as a stable identifier, and build a robust reconciliation pipeline with secure webhooks. Affilentra as a self-hosted platform supports these patterns through separate roles, persistent link ID storage, webhook integrations and transparent commission accounting.
Act now: Choose your entry into Affilentra and configure server-side link IDs as well as hashed email postbacks to immediately reduce tracking gaps. Choose entry: https://affilentra.de
Next step
Try Affilentra yourself
A unified platform that transparently brings together product provisioning, tracking, conversion validation, commission calculation and payout along clearly separated roles; option for self-hosted installation with a perpetual license without revenue share; merchants retain control over products, terms and creatives; partners receive personal tracking links and a traceable payout history.