Hi @fpalacios, What I’ve seen cause “referral link used, but not attributed” most often
1) The candidate’s application is created outside Eightfold (ATS-native apply), so attribution can’t be written
If the candidate ultimately applies directly in Workday (or another ATS) and the application is not created by Eightfold, Workday won’t receive the referral info “during application creation,” and attribution won’t show correctly in Eightfold. In other words: for Workday, referral attribution depends on the apply being created through Eightfold’s SmartApply / PCS flow.
Related confirmation I’ve seen internally: for Workday specifically, “neither classic nor social referral flows creates an application unless candidate applies on its own.” That makes it easy for customers to experience “we referred them / they used the link” but still not see attribution if the apply path leaves Eightfold.
Best practice: make sure referral candidates land on an Eightfold-hosted apply flow (SmartApply/PCS) for the actual submit, not a Workday-hosted apply page.
2) The referral parameter can disappear from the URL during browsing, but should be preserved only within the same backend session
There’s a known behavioral concern people run into: if a candidate comes in on a URL containing ref_src, then clicks around (searches, opens a different job, etc.), the ref_src query param may no longer appear in the browser URL. Engineering guidance in that thread was that Eightfold saves it “in the session… on the backend layer” and reuses it “till the time session is valid.”
Implication: attribution is safest when the candidate:
- clicks the referral link and continues the journey in the same browser session, and
- completes the application without switching devices/browsers or starting a brand-new session.
3) “Source/referrer” capture gaps (common when referrer headers are missing or the candidate starts in a new tab)
Even outside the referral-specific case, Eightfold’s source tracking logic relies on URL parameters (utm_source, src / source) and then the HTTP Referer header; if none exist, it defaults to “Eightfold.” The docs explicitly call out referrer being empty “when a candidate types the URL directly or navigates from a new tab.”
Best practice: ensure the referral links you distribute are the actual clickable links candidates use (not copied into a new tab in a way that loses referrer context), and avoid any intermediate redirects that strip query parameters or referrer headers.
Config / operational best practices that improve referral capture
A) Ensure your candidate emails/templates include the correct apply links
If you’re using job cart referrals, Eightfold supports sending a candidate an email that includes {{jobCartPositionDetails}} (links per job) so they can click straight into the specific job(s) and apply.
B) Validate the “referral vs source tracking” expectations in reporting
Eightfold reporting buckets “Referral” separately when “the application came through a referral flow.” If you’re seeing referred candidates land under another bucket (or under “Other”), it’s a sign the application wasn’t recognized as coming through the referral flow or the captured values weren’t mapped as expected.
A quick troubleshooting checklist (what I’d verify first)
- Which ATS are you using for the final application submit (Workday vs others)? Workday has the specific constraint above where attribution hinges on SmartApply/PCS creating the application.
- Does the candidate apply entirely through the Eightfold flow, in one session? Session breaks can be the difference between attribution sticking vs being lost.
- Are candidates ever getting redirected to ATS-native apply pages? If yes (especially in Workday), that’s a prime suspect.
- Are you relying on referrer headers that might be stripped by your CMS/redirects/new-tab behavior? If referrer/params are missing, capture can default.
