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

# Cookies and browser storage in Default

> Every cookie and browser storage item the Default Pixel and scheduler use, which product part each one belongs to, which ones are strictly necessary and why, and how to set up your consent banner.

This page lists every cookie and browser storage item that Default uses on your website. For
each one it says which part of Default needs it, why, and whether a visitor can turn it off.
Use it to fill in your consent banner, your cookie scanner, and your privacy policy.

**The short answer:** your forms and the scheduler need no tracking cookies. Everything that
recognizes a visitor across visits, or identifies a visitor who has not filled in a form, is
optional. On your own pages it switches off when the visitor says no. The scheduler page is
the one exception today, see [The scheduler page](#the-scheduler-page).

<Note>
  This page describes how Default works. It is not legal advice. How you classify each item,
  and which laws apply to your visitors, is a decision for your own privacy or legal team.
</Note>

## At a glance

| Part of Default | What it stores | Category | Turned off by |
| - | - | - | - |
| Form capture | Nothing | Not needed | Cannot be turned off. The visitor chose to submit. |
| Scheduler after a form | `__default_pending_scheduler_handoff__` (only on redirect) | Strictly necessary | Cannot be turned off |
| Remembering consent | `_dflt_consent` | Strictly necessary | Cannot be turned off |
| Visitor analytics and the Account Signal | `_dflt_aid`, `_dflt_sid`, `_dflt_la` | Analytics | Analytics consent |
| People Signal (Vector) | `_dflt_wi`, plus Vector's own cookies | Marketing | Marketing consent |
| The scheduler page itself | See [The scheduler page](#the-scheduler-page) | Mixed | Not by your banner today |

The Pixel sets its cookies on your own domain (for example `.yourcompany.com`), so they are
first-party cookies. Items marked `sessionStorage` live only in that browser tab and are gone
when the tab closes.

## Strictly necessary

These make the thing the visitor asked for work. Without them, a visitor who submits a form
would not see the scheduler.

### Form capture: no storage needed

When a visitor fills in your form and selects submit, they choose to send you that
information so you can respond. Default captures the submission, runs your workflow, and uses
what they typed to show them the right scheduler with their details filled in. This needs no
cookie. It works the same whether the visitor accepted or declined tracking.

### The scheduler after a form

| Name | Where | Lifetime | Why it is needed |
| - | - | - | - |
| `__default_pending_scheduler_handoff__` | `sessionStorage` | Up to 30 minutes, cleared with the tab | Carries the scheduler link from your form to the next page. |

Default only writes this when your workflow opens the scheduler on another page, for example
after your form sends the visitor to a thank-you page (**Redirect to scheduler page** on the
**Display Scheduler** step). It holds the link to the scheduler the visitor is about to see,
nothing about the visitor. When the scheduler opens on the same page as the form, nothing is
stored. See [How Default books a meeting from a form submission](/forms/scheduler).

### Remembering the visitor's consent choice

| Name | Where | Lifetime | Why it is needed |
| - | - | - | - |
| `_dflt_consent` | Cookie | 1 year | Remembers what the visitor chose, so Default respects it on every page and every visit. |

It holds only the choice itself: whether analytics and marketing are allowed. Default writes it
only after your consent banner tells Default the visitor's answer.

## Analytics

These let Default recognize the same visitor across pages and visits. They are optional.

| Name | Where | Lifetime | What it does |
| - | - | - | - |
| `_dflt_aid` | Cookie and `sessionStorage` | 1 year | An anonymous visitor ID, made from a browser fingerprint. It links a visitor's visits together. |
| `_dflt_sid` | Cookie and `sessionStorage` | Cookie kept 1 year | The current session. A new session starts after 30 minutes without activity. |
| `_dflt_la` | Cookie and `sessionStorage` | Cookie kept 1 year | The time of the visitor's last activity, used for that 30-minute window. |

What they power:

* **Page views and sessions** for your website, so you can see which pages a lead read before
  they submitted.
* **The Account Signal** in [Reveal](/forms/reveal): the real-time lookup of the company behind
  a visit. It runs from the start of a session, so it cannot run without analytics consent.

When a visitor declines analytics, the Pixel writes none of these, deletes any it wrote before,
and does not run the fingerprint. Forms and the scheduler keep working.

## Marketing

These identify visitors who have **not** filled in a form. They are optional.

The **People Signal** in [Reveal](/forms/reveal) uses Default's partner Vector to identify a
visitor as a person, by name, title, and email, so your team can follow up with people who
showed interest but never filled in a form. Results arrive in batches, about every 30 minutes,
and can start a workflow. The Pixel loads Vector's script on every page where it is installed,
as long as Vector is on under **Settings → Integrations**. See [Vector](/settings/integrations/vector).

| Name | Set by | Where | Lifetime | What it does |
| - | - | - | - | - |
| `_dflt_wi` | Default | `sessionStorage` | 30 minutes | Remembers whether the People Signal is turned on for your workspace, so the Pixel does not ask again on every page. |
| `_lc2_fpi` | Vector's identity partner | Cookie | 400 days | Identifier used to match the visitor to a person. |
| `_lc2_fpi_js` | Vector's identity partner | Cookie | Varies | Identifier used to match the visitor to a person. |
| `_li_dcdm_c` | Vector's identity partner | Cookie | Varies | Identifier used to match the visitor to a person. |
| `_li_duid` | Vector's identity partner | `localStorage` | Until cleared | Identifier used to match the visitor to a person. |

When a visitor declines marketing before Vector loads, the Pixel does not load it, so none of
these are set. If a visitor withdraws marketing consent after Vector has already loaded, the
Pixel stops loading Vector on later pages, but it cannot remove the script from the open page or
delete the cookies Vector already set. Send the visitor's answer before tracking starts (see
[Recommended setup](#recommended-setup)) so this does not happen.
If you don't use the People Signal, turn Vector off and the Pixel stops loading it for every
visitor.

## The scheduler page

The scheduler itself is a Default page at `book.default.com`. When it opens on your site, it
shows inside a frame, so what it stores belongs to Default's domain, not yours. It stores these
items itself, and today they don't follow the choice your banner passes to the Pixel.

| Name | Where | What it does | Category |
| - | - | - | - |
| `default.reservation` | `sessionStorage` | Holds the time slot while the visitor finishes booking, so nobody else books it. | Strictly necessary |
| `__rum_sid` | Cookie, ends after 15 minutes without activity | Groups errors and load times from one visit, so Default can fix problems with the scheduler. | Performance |
| `_dflt_aid` | Cookie and `sessionStorage`, 1 year | An anonymous visitor ID made from a browser fingerprint, attached to the booking. | Analytics |
| `_dflt_sid`, `_dflt_la` | Cookie and `sessionStorage`, 1 year | The session and last-activity time, written when the visitor books. | Analytics |
| `ph_<project>_posthog` and related `ph_` items | Cookie, `localStorage`, `sessionStorage`, 1 year | Product analytics on how visitors use the scheduler. | Analytics |

When the scheduler opens inside your site, most browsers block its analytics cookies, because
they belong to another domain. The scheduler then keeps the same IDs in the browser's storage
for that frame instead. A visitor who opens a booking link directly, for example from an email,
gets the cookies as listed.

## Recommended setup

<Steps>
  <Step title="Install the Pixel outside your consent gate">
    Load the Pixel on every page, for every visitor. Don't wait for consent before loading it.
    Your banner controls what the Pixel tracks; it should not control whether the Pixel loads. If
    the Pixel only loads after consent, a visitor who declines, or ignores the banner, submits your
    form and never sees the scheduler.
  </Step>

  <Step title="Send a no before tracking starts, where you need opt-in">
    Out of the box, the Pixel allows analytics and marketing until it hears otherwise. If your
    visitors must opt in first (for example under GDPR), tell the Pixel "no" on the visitor's first
    page, right after the install snippet and before they have made a choice. A call made before the
    Pixel finishes loading is applied before it starts any tracking:

    ```js theme={null}
    function hasStoredDefaultChoice() {
      var match = document.cookie.match(/(?:^|;\s*)_dflt_consent=([^;]*)/);
      if (!match) return false;
      try {
        var stored = JSON.parse(decodeURIComponent(match[1]));
        return stored.v === 1 && typeof stored.analytics === 'boolean' && typeof stored.marketing === 'boolean';
      } catch (e) {
        return false;
      }
    }
    if (!hasStoredDefaultChoice()) {
      window.__defaultPixel__.setConsent({ analytics: false, marketing: false });
    }
    ```

    The check means you only send it while no usable choice is stored. A damaged or outdated
    `_dflt_consent` cookie counts as no choice, the same way the Pixel treats it. Don't send "no" on every page load
    while your banner is still loading; that clears the visitor's ID on every page. Your forms and
    the scheduler keep working while the answer is "no".
  </Step>

  <Step title="Tell Default what the visitor chose">
    When the visitor answers your banner, pass the answer on:

    ```js theme={null}
    window.__defaultPixel__.setConsent({ analytics: true, marketing: false });
    ```

    Default remembers it in `_dflt_consent` for later pages and visits. See
    [Wiring up your consent banner](/forms/privacy#wiring-up-your-consent-banner).
  </Step>

  <Step title="Treat a browser privacy signal as a no">
    Some browsers, such as Brave, send Global Privacy Control (a "do not sell or share my data"
    signal) by default. If your site honors it, keep loading the Pixel and send a no for both
    categories:

    ```js theme={null}
    if (navigator.globalPrivacyControl === true) {
      window.__defaultPixel__.setConsent({ analytics: false, marketing: false });
    }
    ```

    The visitor's form submission and the scheduler keep working. On your pages, the Pixel stores
    no visitor ID, does not run the fingerprint, and does not load Vector. The scheduler page itself
    still stores its own items today (see [The scheduler page](#the-scheduler-page)). Don't skip the
    Pixel for these visitors: that also stops the scheduler. Send this before tracking starts, the
    same way as the opt-in "no" above.
  </Step>

  <Step title="Classify the items in your cookie tool">
    Add the items on this page to your consent tool under the categories in
    [At a glance](#at-a-glance). Most tools, such as Cookiebot and OneTrust, let you add an item
    by name and pick its category.
  </Step>

  <Step title="Mention Default in your privacy policy">
    Name Default as the service that captures your form submissions and runs your scheduler. If you
    use the People Signal, also say that a partner identifies visitors on your site.
  </Step>
</Steps>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.