> ## Documentation Index
> Fetch the complete documentation index at: https://docs.inploi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Analytics Plugin

> How the inploi SDK tracks candidate activity, captures UTM parameters, and attributes sessions through to application submission.

# 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 |

No configuration is needed. The SDK generates and maintains these identifiers automatically.

The `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.

```typescript theme={null}
// Only initialise once the visitor has accepted analytics cookies
onConsentGranted(() => {
  const sdk = initialiseSdk({ publishableKey: 'pk_...', env: 'production' });
  // register and render plugins here
});
```

To stop tracking for a visitor who withdraws consent, do not initialise the SDK on subsequent page loads and clear the `isdk_session` cookie from your domain.

<Note>
  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.
</Note>

## 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`                 |

All five parameters are captured. You do not need to configure anything in Studio or the SDK for this to work — if the parameter is present in the URL, it is stored.

### Example tagged URL

```text theme={null}
https://careers.yourcompany.com/jobs?utm_source=linkedin&utm_medium=cpc&utm_campaign=graduate-intake-2026&utm_content=banner-a
```

<Note>
  Only the parameters present in the landing URL are stored. Missing parameters are not recorded as empty strings.
</Note>

### 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                         |

These parameters are used alongside UTM params in Studio Insights and for source attribution. If you are running managed job distribution through inploi, these are populated automatically — you do not need to set them manually.

## 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](/studio/insights/faqs/track-candidate-sources) 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:

1. `in_placement_id` — if the candidate arrived via an inploi-managed placement
2. `in_platform_id` — resolved to the platform name (e.g. `Indeed`)
3. `utm_source` — the UTM source value from the landing URL
4. The referring domain — if no UTM or inploi parameters are present
5. `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.

<Note>
  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.
</Note>

## 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.

```typescript theme={null}
analytics.log({
  event: 'VIEW_JOB',
  properties: { job: { id: 'abc123', id_type: 'external' } },
  customProperties: {
    brand: 'retail',
    region: 'north-west',
  },
});
```

Custom properties are stored against the event in inploi's analytics data. Contact your Customer Success Manager if you want to surface them in Custom Reports.

When using the Chatbot plugin, you can set `customProperties` at the plugin level to have them merged into all events fired during that session:

```typescript theme={null}
sdk.register(chatbot({
  analytics: {
    customProperties: {
      brand: 'retail',
    },
  },
  // ...
}));
```

## Related

* [UTM and campaign tracking](/studio/insights/faqs/track-candidate-sources) — practical guide to tagging job posting links and aligning with an existing campaign taxonomy
* [Sources](/studio/insights/sources) — how to read the Sources and Campaigns views in Studio Insights
* [Custom Reports](/studio/insights/custom-reports) — build bespoke reporting views in Studio Insights