Overview

Eightfold tracks where candidates and applications come from at two levels:

1. Person-level source tracking: where a candidate profile originated, even before any application exists.
2. Application-level source tracking: Which channel led to a specific application, captured through UTM parameters, HTTP referrers, and session cookies on the Personalised Career Site (PCS).

Source tracking tells recruiting teams which channels attract candidates and generate applications. This evidence justifies marketing spend and distribution investment per channel.

An application is rarely the result of a single touch. A candidate may be engaged through sourcing, campaigns, events, and communities over months yet discover the actual apply link through an entirely different path, such as a Google search or a job board click. Eightfold therefore separates two questions:

1. Who/What engaged this candidate over time? Answered by top-of-the-funnel attribution (multi-touch).
2. Which path delivered this specific application? Answered by bottom-of-the-funnel application source tracking (last-touch).

Top-of-the-Funnel Attribution

Per-Person Source Tracking

A candidate's resume can enter Eightfold without the prospect ever applying, for example, through screening events or conferences. Capturing the source of each prospect shows which channels build the passive talent pool.

Person source tracking replaces the rigid tag-based approach with a structured, configurable source framework:

1. Admins define custom source categories (e.g., “university recruiting" and “social media") and map them to UTM parameters and ATS identifiers.
2. Every person record captures Source and Sourced By when the profile first enters the system, visible on the Profile Top Card.
3. Recruiters can manually select or override a source during resume import, with 'Sourced By' pre-filled to the logged-in user.
4. All source changes are audit-logged for accountability.

Note: These fields are largely static. Recruiters should update them only when the candidate becomes active on a different channel. If a profile is created with a source and the same candidate’s profile is updated with new source, the source field won’t get updated.

Prospect Ownership

Once a profile enters the system or is rediscovered from the talent network, the challenge is ensuring the right recruiter engages the prospect without duplicate outreach or missed follow-ups. Prospect Ownership solves this by assigning a named, time-bound owner to each profile, making engagement accountability explicit.

1. Every candidate profile carries a Prospect Owner field, visible on the Profile Top Card and in pipeline views.
2. Ownership is time-bound and auto-expires after an admin-configured period, so stale assignments never block re-engagement.
3. Sourcers are automatically assigned ownership when they import a profile via Resume Import or LinkedIn CRM.
4. Bulk ownership assignment and transfer are available across pipeline, candidate pages, and profile views.
5. Workflow automation can assign ownership on triggers: prospect contacted, prospect replied, or stage change.
6. All ownership changes are tracked in the profile activity log for a full attribution history.
7. The prospect owner receives application and hire attribution if the prospect applies within the ownership window.

Email Campaigns

Recruitment marketers create branded campaigns to nurture existing profiles, often ahead of upcoming events. Email campaigns use 90-day multi-touch attribution: if a candidate applies within the window, every campaign the prospect was part of receives attribution. Attribution is recorded in the data warehouse layer.

Note: recruiters can create thin profiles for prospects (for example, from resumes collected at events or conferences) so those prospects can be engaged from the platform.

Recruiting Events

After a prospect engages sufficiently with a campaign, recruiters invite them to an event, where resumes are collected and initial screening happens. Events also use 90-day multi-touch attribution: if a candidate applies within 90 days, every event the prospect attended receives attribution. Attribution is recorded in the data warehouse layer.

Community

Leads from events may be invited to apply directly or moved into communities for long-term nurturing based on defined criteria. Communities also use 90-day multi-touch attribution: if a prospect applies within 90 days, every community the prospect belonged to receives attribution. Attribution is recorded in the data warehouse layer, where analytics teams can build custom reports for top-of-the-funnel activities.

Bottom-of-the-Funnel: Job Distribution and Application Source Tracking

Eightfold distributes jobs through direct job board integrations and tracking links. Regardless of how a candidate was engaged at the top of the funnel, every application ultimately happens on a PCS job URL, and the candidate may discover that URL through a completely different path. A prospect nurtured for months through campaigns may still find the apply link via a Google search.

Application source tracking answers two questions:

• For recruiters: how did this candidate find this job?
• For recruitment marketing: how effective and efficient is each channel?

How a Source Is Captured on PCS

For every visitor session, PCS takes the first available signal, in strict priority order:

1. utm_source URL parameter in the link the visitor clicked (e.g., ...careers?utm_source=google&utm_campaign=my_test_campaign). utm_campaign is captured alongside it. Eightfold's job board distribution feed threads these values into apply URLs.
2. src or source URL parameter, which many job boards append (e.g., ...&src=indeed).
3. HTTP referrer, inferred from the page that linked to PCS.
4. Previous source on the visitor's cookie (vs_cookie), valid for 7 days, used when the current visit carries no signal.
5. Default ('Eightfold', configurable), e.g., when a visitor types the career site URL directly.

The captured value is then mapped to an ATS-readable 'source code' via the configurable referrersrcmap and written back to your ATS on application submit. Eightfold pulls it back from the ATS and surfaces it on the applicant's recruiting activity page in pipeline view. Mapping rules, worked examples, and link-off PCS configuration are covered in Appendix A.

Attribution Models: Single-Touch and Multi-Touch Together

Consider this journey:

Career fair (left contact info) → recruiter email invitation → Google search for the company → landed on PCS → applied.

The candidate was engaged through the career fair and the recruiter (top of funnel), but discovered the apply link through Google (bottom of funnel). Both stories are true, so Eightfold reports both.

Last-touch attribution (single-touch, the default)

Eightfold reports the last source from which the application happened: PCS (via Google). This is the source recruiters see on the application in Talent Acquisition, and the default on the Career Site and Source Analytics Dashboard. It answers: which channel delivered the application?

Multi-touch attribution

Career fair, recruiter, and PCS (via Google) all receive attribution in the multi-touch section of the Career Site and Source Analytics Dashboard. This connects bottom-of-funnel applications back to top-of-funnel engagement (campaigns, events, communities, each within their 90-day windows). It answers: which channels contributed to this candidate applying? Multi-touch sources are not shown in the TA UI.

How the two models read together

PCS activity source (traffic, not applications)

Separately, PCS reports the last source of every visit, whether or not an application followed. Two limits to remember:

1. Only the last hop is visible: in Google → LinkedIn → PCS, the PCS source is LinkedIn; Google (the source to LinkedIn) cannot be captured.
2. The cookie's source memory expires after 7 days; after that, a returning visitor counts as direct traffic.

Implementation

Standardize UTMs across all job distribution

Include utm_source (and utm_campaign for campaign rollups) on every link posted to job boards, emails, and paid campaigns. Because capture follows a strict precedence (utm_source → legacy src/source → mapped referrer → stored session → default), a consistent UTM strategy resolves most traffic at the strongest signal and never depends on fragile referrers. UTMs travel in the URL, so they also survive browser privacy features that strip referrers.

In practice, most companies reliably populate only utm_source; medium, campaign, content, and term are filled inconsistently, if at all. Wherever a system appends a value automatically (a feed, an ad platform, an integration), the data stays clean; wherever a person types it by hand, the data drifts. The conventions below remove the dependence on manual discipline:

utm_source

• Lowercase, single-word platform names, always the same spelling.
• Maintain a short approved list with a simple request process for new values.
• Never your own company name; audit internal banners and redirects for this.
• Platform only; keep paid/organic and vendor details out of this field.

utm_campaign

• One naming pattern: lowercase, no spaces, fixed segments (e.g., year, region, team, initiative).
• Never platform names here; that is the source field's job. Short codes are fine if a reference list exists.

To enforce these conventions, build them into tooling: generate links through a URL builder that only offers approved values, give the source dictionary a named owner, and hold automated tags (feeds and integrations) to the same conventions as human-built links.

Use the PCS XML job feeds to carry UTMs

Per-feed URL templates auto-append UTMs with no human typing, so the feed is the controlled mechanism for tagging job-board traffic. Provide boards a feed URL that threads utm_source/utm_campaign into every apply URL, and verify the values survive into the final click URL on the board's side. Tagging then becomes a template-update request, not a manual program.

Protect the referrer where UTMs are impossible

Where a partner cannot pass UTMs, make sure they at least pass the HTTP referrer cleanly: no noreferrer link patterns, no unnecessary redirect hops. The referrer fallback catches untagged and emerging channels (referrers surface emerging channels such as AI assistants with no tagging effort), so suppressing it pushes real channels into the unattributed bucket.

Verify the writeback lands in the right ATS fields

After mapping, confirm the source code is written to the ATS field that is later synced and reported on (commonly source_type / source_name, depending on the ATS and integration). A correct map pointed at the wrong target field still produces 'missing' sources in analytics.

Linkoff flows: configure the redirect and the resume modal

Where 'Apply' redirects to the ATS, configure 'apply_redirect_url' so source parameters survive the redirect and enable the 'Upload resume' modal before the redirect so the visitor session can be connected to the eventual ATS application. Missing either silently breaks attribution for the whole flow.

CMS in front of PCS: set up source continuity

Traffic flowing Google → CMS → PCS gets attributed to the CMS (or to the default) unless the CMS-to-Eightfold handoff script carries the original referrer/source forward. Caveat: the approach depends on browser cookie behaviour (third-party cookies must be enabled), so treat it as high-impact but not loss-free.

Recruiter-shared links: personalized apply URLs

Recruiter and employee shares without UTMs are one of the most common drivers of unattributed volume. Where recruiter attribution matters, issue outreach links with UTMs (e.g., utm_source=recruiter&utm_campaign=<recruiter_id>) so the apply event carries attribution into the analytics tables.

Budget for an unattributed floor, and label it honestly

Report the Eightfold default as 'direct / unknown', not as a channel. Expect a floor of roughly 2-12% of volume; well-governed setups hold 2-4%. Set that band as the hygiene KPI; 'zero unattributed' is not an achievable success criterion, and tracking cannot be reconstructed retroactively: if the source was not captured at session time, it is gone.