---
title: Rokt Pixel
slug: rokt-pixel
docTags: 
createdAt: 2026-10-06T19:54:17.672Z
---

Rokt is an advertising and offer-placement network. The Rokt Pixel destination loads Rokt's Web SDK in the browser and records conversions and page views, so Rokt can attribute a purchase or signup back to the campaign that drove it and build retargeting audiences.

For the server-side equivalent, see [Rokt Events API](https://rokt-conversions.md). The two can run together — see **Using Alongside the Rokt Events API** below.

# Getting Started

ou need one value, and one thing removed.

**Your Rokt credential.** Rokt runs two browser SDKs and provisions an account for one or the other, so paste whichever value **my.rokt.com > Integrations > Set up the Snippet** gave you and Chord loads the matching integration:

- If your snippet loads from `apps.rokt-api.com` and carries an **API Key**, put it in **API Key**.
- If your snippet calls `createLauncher({ accountId })` and loads `launcher.js`, put that value in **Account ID**.

Fill in one, not both. They are not interchangeable — an Account ID in the API Key field produces a `404` from Rokt's CDN and nothing loads. Neither is the API key and secret pair the [Rokt Events API](https://rokt-conversions.md) destination uses.

:::BlockQuote
**The Account ID integration can display Rokt offers on your site.** Its only entry point is Rokt's offer-selection call, so on each conversion Chord asks Rokt for a placement and Rokt may render an overlay, an embedded unit, or an interstitial on your confirmation page. What renders, and whether anything does, is controlled by what you configure in Rokt. The API Key integration records conversions without requesting placements.
:::

**Remove any Rokt snippet you installed yourself.** This destination replaces it. Two copies of Rokt's SDK on one page initialize twice and report every conversion twice.

Two settings are worth a decision:

- **Email Format** — whether the shopper's email is sent raw or as a SHA-256 hash. Rokt matches conversions to campaigns on the email address and accepts either, and their own setup wizard recommends the raw address, so that is the default here. Switch to hashed if your security policy does not allow a plain email address in the page's network traffic — Rokt matches either form, so this costs you nothing in attribution.
- **Development Mode** — routes events to Rokt's development data environment. Turn it on while you are testing and off before launch. Rokt does not report on development data.

**Custom Event Mapping** is optional. See **Event Mapping** below for when you need it.

# Connecting to the Rokt Pixel CDP Destination

:::BlockQuote
**Warning:** Before connecting destinations in the Chord CDP, please verify with all Destination owners that all **non-Chord CDP** configured destinations are **disabled**. Running external destinations alongside configured Chord CDP destinations **can result in duplicate events downstream.**
:::

1. Log into the Chord data platform.
2. Navigate to the CDP.
3. Click the **"Add"** button next to Destinations.
4. Select **Rokt Pixel** from the destination catalog.
5. Enter the destination name and either your **API Key** or your **Account ID**, and choose an **Email Format**.
6. Click **"Create"** to connect.
7. Connect it to your **front-end** site.
8. Remove your own Rokt snippet from the storefront.

# Event Mapping

Rokt records a conversion as a single event named `conversion`, with a `conversiontype` attribute saying what kind it was. Chord maps events like this:

| Chord event                 | Rokt `conversiontype`                                                        |
| --------------------------- | ---------------------------------------------------------------------------- |
| `Order Completed`           | `purchase`                                                                   |
| `Signed Up`, `User Created` | `signup`                                                                     |
| `Subscription Created`      | `subscription`                                                               |
| Page views                  | `screen_view`, sent through Rokt's page view call (API Key integration only) |

On the Account ID integration, page views are not sent: Rokt's offer-selection call is the only entry point it has, and asking for a placement on every page is not what it is for. Conversions are sent identically on both.

**Anything not in that table is skipped**, and the skip is written to the browser console so you can see it happened. Use **Custom Event Mapping** to route an additional event onto one of the four conversion types — for example `Trial Started` → `subscription`. A mapping naming anything outside those four values is ignored.

If the Rokt Events API destination has been enabled for your store, **configure the same mapping on both**. Otherwise the same conversion is classified one way in the browser and another way from the server.

:::BlockQuote
Rokt's public documentation describes `conversiontype` as free text and lists further example values elsewhere, without publishing a definitive set. Chord sends only the four above until Rokt confirms which values their reporting acts on. If you need another one, ask your Rokt account manager to confirm it and we will add it to both destinations together.
:::

# Identity and User Attributes

Rokt matches a conversion to a campaign on the shopper's email address, so a conversion without one will not attribute.

The address is lowercased and trimmed before it is sent, which is the same rule Rokt specifies before hashing. That means switching **Email Format** does not change which shopper Rokt resolves — only whether the address is readable in the page's network traffic.

Alongside the email, Chord sends Rokt's recommended user attributes when your events carry them — first name, last name, mobile number, city, state and postal code — each with its SHA-256 counterpart where Rokt defines one. Rokt's own canonicalization rules are applied before hashing: lowercase and trim for email and names, digits only for the mobile number.

The Rokt Click ID needs no configuration here. Rokt's SDK captures it itself when it initializes and attaches it to conversions.

# Deduplication

Rokt deduplicates on `confirmationref`. Chord sends your order ID there for purchases, and for conversions with no order — a signup, say — it sends the event's `messageId` instead, so every conversion carries a stable reference.

It is also what makes it safe to run this destination alongside the Rokt Events API destination, where that has been enabled: both derive `confirmationref` the same way, so Rokt sees one conversion rather than two. If you push conversions into the same Rokt account from another system, `confirmationref` is the value to deduplicate against.

# Custom Properties

Rokt accepts custom attributes on a conversion, so any property mapping you configure is forwarded alongside the standard attributes. Use a bare property path in the mapping's destination field.

Mapped properties cannot overwrite the attributes Rokt defines itself — `conversiontype`, `confirmationref`, `amount` and `currency` are reserved and always carry Chord's computed values.

# Empty Carts

An `Order Completed` with no products does not fire a conversion. An empty purchase is almost always a tracking fault rather than a real order, and reporting it inflates Rokt's conversion count with something you cannot reconcile.

# Content Security Policy

If your storefront enforces a Content Security Policy — every Hydrogen storefront does by default — Rokt will not load until these hosts are allowed. The symptom of a missing entry is a destination that looks connected and sends nothing.

| Directive     | Hosts                                                                                  | Needed for                                    |
| ------------- | -------------------------------------------------------------------------------------- | --------------------------------------------- |
| `script-src`  | `https://apps.rokt.com`, `https://apps.rokt-api.com`, `https://apps.roktecommerce.com` | loading the SDK                               |
| `connect-src` | `https://apps.rokt.com`, `https://apps.rokt-api.com`, `https://apps.roktecommerce.com` | sending conversions                           |
| `frame-src`   | `https://apps.rokt.com`                                                                | the offer placement, which renders in a frame |
| `font-src`    | `https://apps.rokt.com`                                                                | the icon font the placement uses              |

`apps.rokt.com` serves the Account ID integration; `apps.rokt-api.com` and `apps.roktecommerce.com` serve the API Key one. Allowing all three covers either, and costs nothing if you only use one.

`apps.roktecommerce.com` is Rokt's documented fallback host — the API Key SDK retries there when the primary CDN is blocked, so omitting it removes the fallback that keeps the pixel working behind some ad blockers.

`frame-src`**&#x20;and&#x20;**`font-src`**&#x20;are only needed for the Account ID integration**, and only because it renders an offer. They are not in Rokt's published CSP guidance — we found them by watching the network tab during a live conversion, where the placement pulled an HTML document and `rokt-icons.woff` from `apps.rokt.com`. If your policy does not set `font-src` explicitly it will inherit your `default-src`, which may already permit it.

Your storefront team applies this, usually in a different repository from your Chord configuration. If you use a Rokt first-party collection domain, allow that host too.

This list was confirmed against a live storefront for the Account ID integration. The API Key integration's hosts come from Rokt's published guidance and have not been exercised live, so treat those as a starting point and check the browser console for violations on your first test.

