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. The two can run together — see Using Alongside the Rokt Events API below.

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:

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 destination uses.

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:

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

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

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.

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.

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.

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.

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.

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.

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 and font-src 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.