User Sync for WordPress Affiliate Networks:
Tracking Referrals Across Domains
An affiliate drives a signup on your main site. The customer converts on your sub-brand site. The referral credit disappears into the gap between two disconnected WordPress databases. This guide covers the full architecture for affiliate user tracking across multi-domain WordPress networks — so every referral gets attributed correctly, every time.
Updated 2026
Affiliate Network Architecture Guide

Affiliate networks built on WordPress are particularly vulnerable to a referral attribution failure that most network operators discover only when affiliates start complaining about missing commissions. The failure has a consistent pattern: an affiliate recruits a user who registers on the main site. The user later converts — makes a purchase, upgrades to a paid plan, or completes a high-value action — on a connected sub-domain, regional site, or sister brand. The conversion happens, the revenue lands, but the affiliate commission does not fire because the conversion event occurred on a different domain than the one where the referral was originally tracked.
This is the cross-domain referral attribution problem, and it sits at the intersection of two technical systems that were not designed to talk to each other by default: the affiliate tracking system that lives on one WordPress installation, and the conversion events that occur on another. Solving it requires understanding both the user identity layer (the sync problem) and the referral attribution layer (the tracking problem) and how they interact in a multi-domain affiliate network architecture.
This guide covers the full picture: how affiliate plugins store referral data in WordPress, the specific ways cross-domain networks break attribution, the user sync architecture that preserves affiliate identity across domains, and how WordPress affiliate network cross-domain user sync provides the identity layer that referral tracking depends on. We reference AffiliateWP — the most widely deployed WordPress affiliate plugin — throughout, with notes on how the same principles apply to other affiliate platforms.
This guide is written for affiliate network operators and WordPress developers who build and maintain multi-domain affiliate programs. It assumes familiarity with how affiliate programs work generally but covers the WordPress-specific technical details that make cross-domain attribution a distinct architectural challenge.
How affiliate plugins store referral data in WordPress: what you need to know
Affiliate attribution in WordPress exists at two levels: the referral link level (cookie-based tracking that connects a visitor’s session to an affiliate’s ID) and the conversion level (a database record that connects a completed action to the referral that preceded it). The cross-domain attribution problem primarily affects the second level — the point where a conversion event occurs and the affiliate credit needs to be assigned.
Understanding how AffiliateWP specifically stores this data illuminates exactly where the attribution breaks in a multi-domain setup.
AffiliateWP stores its data in custom tables: wp_affiliate_wp_affiliates (affiliate accounts), wp_affiliate_wp_referrals (conversion records), wp_affiliate_wp_visits (click tracking), and wp_affiliate_wp_payouts (commission payments). Each affiliate account is linked to a WordPress user via user_id. Each referral record stores the affiliate_id, the reference (the order ID or user ID being attributed), the commission amount, and the status.
AffiliateWP sets a cookie (affwp_ref) on the visitor’s browser when they arrive via an affiliate link. This cookie stores the affiliate’s ID and is read by the conversion integration at the moment of purchase or signup. The cookie is set for the domain it originates from. If the affiliate link points to brand.com but the user converts on shop.brand.com or store.anotherbrand.com, the cookie behavior depends on the domain relationship.
.brand.com) are accessible across all subdomains of that domain, including shop.brand.com. AffiliateWP supports this via the affwp_cookie_domain filter. However, cookies cannot cross to entirely different domains (anotherbrand.com). For fully separate domain networks, cookie-based tracking breaks entirely at the domain boundary, and a different attribution mechanism is needed.AffiliateWP stores a user meta key affwp_referral_affiliate on the referred user’s WordPress account at the moment of their registration. This meta key stores the ID of the affiliate who referred them. This is the identity-based attribution record — separate from the cookie-based session tracking, it provides a permanent link between the registered user and the affiliate who recruited them.
affwp_referral_affiliate meta to identify the originating affiliate — even when the cookie has expired, even when the conversion happens months after the original referral, and even when the conversion occurs on a completely different domain.The four ways cross-domain networks break affiliate attribution
Attribution failures in multi-domain WordPress affiliate networks are not random. They cluster around four specific patterns that each have a different technical cause and a different fix. Identifying which pattern is producing the missing commissions in your network is the first step toward resolving them.
An affiliate link drives a visitor to mainbrand.com. The affwp_ref cookie is set on mainbrand.com. The visitor browses products, decides to purchase on storebrand.com where the products are actually sold. The conversion fires on storebrand.com, which has no access to the cookie set on mainbrand.com. No commission fires.
?ref=affiliateID) in the URL when the user crosses domain boundaries. AffiliateWP reads the ref query parameter on landing and sets its cookie on the new domain. The user identity sync (described below) provides a durable identity-based fallback that does not depend on the URL parameter surviving the cross-domain journey.A user registers on the main site via an affiliate link. Their account on the main site has the affwp_referral_affiliate meta correctly set. They later purchase on the conversion domain. But their account was never synced to the conversion domain — they create a new account there, which has no referral meta. Even if a conversion hook on the conversion domain looked for the referral meta, it would find nothing because this account was created independently.
affwp_referral_affiliate meta, must be synced to all conversion domains at the moment of registration on the primary site. With user sync in place and SSO enabling single-account access across domains, the user never creates a duplicate account — they arrive authenticated on the conversion domain and their referral attribution travels with them.The affiliate network is managed entirely from the primary site. AffiliateWP is installed and configured there, with all affiliate accounts, referral records, and payout management centralized. The conversion domain is a WooCommerce store or other site that does not have AffiliateWP installed. When a purchase happens on the conversion domain, there is no local AffiliateWP instance to fire the referral — and the primary site’s AffiliateWP has no visibility into purchases on the conversion domain unless a notification mechanism bridges the two.
In many affiliate networks, the affiliates are also active users of the product — they are customers, members, or creators who receive special affiliate access in addition to their regular account. When an affiliate’s account is suspended, their email is changed, or their payout details are updated on the primary site, those changes need to propagate to every connected domain where their account exists. An affiliate who cannot log in to a connected site to access their affiliate dashboard, check their referral stats, or withdraw earnings will escalate the issue immediately.
affwp_affiliate_id, affiliate status flags) must be included in the metadata sync scope so that their affiliate identity is preserved across all connected domains. SSO ensures they can access their affiliate dashboard on any connected site without re-authenticating.User identity continuity: the prerequisite for cross-domain attribution
Every attribution failure described above ultimately traces back to one root condition: the absence of a reliable, consistent user identity that follows the referred user across domain boundaries. Cookie-based attribution is inherently fragile in multi-domain environments — cookies expire, browsers block third-party cookies, and users clear their browser data. These are session-level mechanisms. What affiliate networks need is an account-level mechanism: a permanent link between the referred user and the affiliate who recruited them that travels with the user’s WordPress account wherever that account is recognized.
User sync provides this mechanism. When the referred user’s account is synced from the primary site to all connected conversion domains — including the affwp_referral_affiliate meta field that records their referral attribution — that attribution becomes a permanent property of their identity on every site in the network. No matter which domain they convert on, no matter how long after the original referral, the attribution record is present and readable by the conversion event handler.
SSO solves a second attribution problem that user sync alone does not address: duplicate account creation. Without SSO, a referred user who arrives on a conversion domain and does not recognize the login page may create a new account with the same email address — or a different one. That new account has no referral meta because it was not created via the original referral path. With SSO in place, the user arrives on the conversion domain already authenticated — they cannot accidentally create a duplicate account because they are already logged in as the same user whose account carries the referral attribution.

The affiliate-specific user meta fields that must be synced
Standard user sync covers the core identity fields. For an affiliate network, several additional user meta fields must be included in the sync scope to ensure that both referral attribution and affiliate account functionality work correctly across all connected domains.
The fields marked “No” are site-specific cached statistics. Syncing them would create misleading data on sub-sites — an affiliate who has referred 200 users on the primary site but has never referred anyone from a specific conversion sub-site would show 200 referrals on that sub-site, which is inaccurate from that site’s perspective. These stats should always be computed from the local site’s data, not inherited from another site via sync.

Architecting a multi-domain affiliate network for attribution accuracy
The technical fixes described above — syncing referral meta fields, passing the ref parameter across domain boundaries, configuring SSO to prevent duplicate accounts — each address a specific failure mode. Combining them into a coherent architecture produces a multi-domain affiliate network where attribution failures are structurally prevented rather than individually patched.
AffiliateWP runs on a single primary site — the affiliate registration hub, dashboard, and payout management are all here. All affiliate accounts exist as WordPress users on this site. All commission records are stored here. Sub-sites in the network are conversion endpoints that report back to this primary site’s affiliate system when conversions occur there.
Every user who registers on the primary site — whether they were referred by an affiliate or not — is synced to all connected conversion sub-sites. The sync includes the affwp_referral_affiliate and affwp_referral_url fields. This means that every user who arrives on a conversion sub-site carries their referral attribution with them in their account.
SSO prevents the duplicate account problem that defeats referral attribution. When a referred user navigates to a conversion sub-site, SSO authenticates them automatically. They arrive as the same user whose account carries the referral meta — not as a new user with a clean, unattributed account. The conversion event handler on the sub-site can query the authenticated user’s referral meta and fire the commission correctly.
When a purchase occurs on a conversion sub-site, a webhook or API call fires to the primary site’s AffiliateWP installation, passing the user ID (or their referral meta value), the order value, and the conversion type. AffiliateWP on the primary site creates the referral record against the affiliate identified by the user’s affwp_referral_affiliate meta. The commission fires. The affiliate’s dashboard on the primary site reflects the cross-domain conversion.
For visitors who arrive via affiliate links but have not yet registered (and therefore have no user account to carry the attribution meta), the referral cookie remains the attribution mechanism. Configure cross-domain navigation links from the primary site to conversion sub-sites to append the active referral parameter from AffiliateWP’s cookie so it is available to the receiving site’s AffiliateWP instance. This covers pre-registration visitors who convert without creating an account first — for example, guest checkouts.
Keeping affiliate accounts current across the network
Affiliate accounts require the same ongoing sync attention as regular customer accounts — arguably more, because the consequences of an out-of-sync affiliate account are visible to people who have a direct financial relationship with your platform and are accustomed to scrutinizing their account details.
affwp_affiliate_id synced immediately.
Configuration checklist: setting up user sync for a WordPress affiliate network
The following checklist covers every configuration step specific to affiliate network user sync deployments. It builds on the standard multi-site sync setup and adds the affiliate-specific items that most general setup guides omit.
affwp_referral_affiliate, affwp_referral_url, and affwp_affiliate_id. These fields are not part of WooCommerce metadata sync — they require explicit inclusion in the general metadata sync scope.affwp_earnings and affwp_referral_count from sync to prevent misleading stats on sub-sites.Affiliate programs run on trust. An affiliate who drives referrals that convert but do not generate commissions will not wait long before leaving your program and telling others why. The technical architecture described in this guide — user sync carrying referral attribution meta, SSO preventing duplicate accounts, and conversion event reporting bridging the gap between domains — is what converts a leaky multi-domain attribution setup into one that affiliates can rely on.
Nexu User Sync’s WordPress affiliate network cross-domain user and referral meta synchronization provides the identity layer that affiliate attribution depends on — syncing referral meta fields alongside core user data, enabling SSO to prevent duplicate accounts, and maintaining affiliate accounts consistently across every domain in your network.
Every referral attributed. Every commission fired. No matter which domain the conversion happens on.
Nexu User Sync gives your affiliate network the identity layer it needs — syncing referral attribution meta across all connected domains, preventing duplicate accounts with SSO, and keeping affiliate accounts consistent everywhere they are recognized.

The affwp_cookie_domain filter is a decent workaround, but it doesn't fully solve the core issue. when users jump between domains, the cookie still drops off unless you manually sync user meta across sites. Had to write custom scripts to push the affwp_affiliate_id meta key between databases shouldn't need to do that for a premium solution. works, but feels like a half fix.
So if a referral record shows the affiliate ID, order ID, commission, and status, does that mean I
Got cross domain referrals working no more manual spreadsheets!
Hey, just wanted to say this solved our cross domain tracking nightmare. had affiliates losing credits left and right when users jumped between our main site and sub brands. Now every referral sticks where it should