Analytics Plugin
The analytics service is built into @inploi/sdk and runs automatically when you initialise the SDK. It collects anonymised candidate activity — page views, job views, application starts, and completions — and ties it to a session that persists across a candidate’s journey. UTM and campaign parameters captured on landing flow through to Studio Insights and, where configured, into the source field of your ATS.
Events are anonymous by default: each one is tied to a randomly generated identifier, not to a named person. No name, email, or phone number is collected unless a candidate voluntarily provides it (for example, by submitting an application or signing up for job alerts).
How analytics works
When you install the inploi SDK, it sends an analytics event to the inploi API every time a candidate interacts with a plugin (views a job, starts an application, submits, and so on). Each event includes the full current URL of the page as part of its context.
On the first event for a new visitor, the API creates a session and extracts any tracking parameters from that URL. Those parameters are stored against the session and used to attribute all subsequent activity — including the final application — to the correct source and campaign.
Session identity
Every candidate visit is assigned three identifiers that the SDK manages automatically:
| Identifier | Storage | Lifetime | Purpose |
|---|
anonymous_id | Cookie (isdk_session) | 7 days | Ties activity across pages and visits |
session_id | sessionStorage | Browser tab | Groups events within a single browsing session |
candidate_id | localStorage | Until cleared | Links a visitor to an identified candidate after they voluntarily submit contact details |
anonymous_id is a randomly generated UUID. It contains no personal data and cannot be reversed into a person’s identity. Until a candidate identifies themselves, all activity is recorded against this anonymous identifier only — candidate_id stays empty.
Cookies and consent
The SDK sets a single first-party cookie, isdk_session, on your own domain. It holds only the random anonymous_id — no personal data — and expires after 7 days. The session_id and candidate_id identifiers are held in sessionStorage and localStorage respectively, not in cookies.
| Item | Type | Contains | Lifetime |
|---|
isdk_session | First-party cookie | Random anonymous_id (UUID) | 7 days |
isdk_session-session_id | sessionStorage | Session identifier | Until the browser tab closes |
isdk_session-candidate_id | localStorage | Candidate identifier (only after identify) | Until cleared |
Managing opt-in
The SDK does not display a cookie consent banner and does not gate analytics behind a built-in consent prompt. Consent management is controlled by you, the site owner, so it fits within your existing cookie policy and consent tooling.
If your policy requires opt-in before any tracking, initialise the SDK only after the visitor has granted consent — for example, from the accept callback of your cookie banner. No cookie is set and no events are sent until initialiseSdk() runs.
// Only initialise once the visitor has accepted analytics cookies
onConsentGranted(() => {
const sdk = initialiseSdk({ publishableKey: 'pk_...', env: 'production' });
// register and render plugins here
});
isdk_session cookie from your domain.
The cookie is classified as functional/analytics — it is used to measure candidate journeys, not for advertising. It is first-party and is never shared with third-party ad networks.
UTM parameters
What is captured
When a candidate arrives at your careers site from a tagged link, the inploi API extracts the following standard UTM parameters from the landing URL:
| Parameter | Purpose | Example value |
|---|
utm_source | The channel or platform sending the candidate | indeed, linkedin, google |
utm_medium | The marketing medium | cpc, organic, email |
utm_campaign | The campaign name | graduate-intake-2026, retail-hiring |
utm_term | A keyword or targeting term | store-manager, pharmacist |
utm_content | A creative variant or ad version | banner-a, text-link |
Example tagged URL
https://careers.yourcompany.com/jobs?utm_source=linkedin&utm_medium=cpc&utm_campaign=graduate-intake-2026&utm_content=banner-a
Only the parameters present in the landing URL are stored. Missing parameters are not recorded as empty strings.
When parameters are captured
Parameters are captured when the session is created — on the first analytics event the SDK sends for that visitor. Because the anonymous_id cookie lasts seven days, a candidate who returns within that window is still attributed to the same session and source.
If a candidate arrives without tracking parameters and later returns via a tagged link, the original (untagged) session is preserved. Attribution uses the first touch.
inploi tracking parameters
In addition to standard UTM parameters, inploi uses its own tracking parameters for managed job distribution. These are appended automatically to job feed URLs and job alert links:
| Parameter | Purpose |
|---|
in_platform_id | Identifies the distribution platform (e.g. Indeed, CV-Library) |
in_campaign_id | Identifies the inploi campaign |
in_placement_id | Identifies the specific placement within a platform |
in_channel_id | Identifies the channel |
in_creative_id | Identifies the creative variant |
in_platform_campaign_id | The platform’s own campaign identifier |
Attribution in Studio Insights
Sources view
The Sources view in Studio Insights breaks down candidate activity and applications by channel. The source shown for each row is derived from the utm_source value captured on landing (or from inploi’s own tracking parameters for inploi-managed placements).
Campaigns view
The Campaigns view shows performance broken down by utm_campaign value. Each distinct campaign name in your tagged URLs becomes a row in this view, showing job views, application starts, completed applications, and (where ATS data is available) hires and cost per hire.
To populate the Campaigns view, include utm_campaign in your job posting links. Use a consistent naming convention — see UTM and campaign tracking for guidance on structuring campaign names.
ATS source field
When a candidate submits an application, inploi forwards a single derived source value to your ATS to populate its source tracking field. This value is determined in the following priority order:
in_placement_id — if the candidate arrived via an inploi-managed placementin_platform_id — resolved to the platform name (e.g. Indeed)utm_source — the UTM source value from the landing URL- The referring domain — if no UTM or inploi parameters are present
direct — if no attribution information is available
The full set of UTM parameters (utm_medium, utm_campaign, utm_content, utm_term) is available in Studio Insights but is not forwarded to the ATS. Only the single derived source value is sent.
ATS source field mapping is configured per integration during implementation. Contact your Customer Success Manager to confirm how the source value is mapped in your ATS.
Custom event properties
You can attach arbitrary data to analytics events using customProperties. This is useful when you want to pass context that is specific to your implementation — for example, a brand identifier or a custom segment.
analytics.log({
event: 'VIEW_JOB',
properties: { job: { id: 'abc123', id_type: 'external' } },
customProperties: {
brand: 'retail',
region: 'north-west',
},
});
customProperties at the plugin level to have them merged into all events fired during that session:
sdk.register(chatbot({
analytics: {
customProperties: {
brand: 'retail',
},
},
// ...
}));
- UTM and campaign tracking — practical guide to tagging job posting links and aligning with an existing campaign taxonomy
- Sources — how to read the Sources and Campaigns views in Studio Insights
- Custom Reports — build bespoke reporting views in Studio Insights
