Cookie Consent Flags

Rokt supports cookie opt-outs so you can align your implementation with user consent preferences. This helps ensure compliance with privacy regulations and provides consistent, respectful experiences when customers opt out of different levels of tracking.

Types of Tracking Technologies

Rokt distinguishes between two categories of tracking technologies. Each serves a different purpose and has different implications for user consent flags.

Functional Tracking Technologies

Functional tracking technologies enhance the usability and performance of a site or app. They are used to remember language or region settings, keep a user logged in during a session, save items in a shopping cart, and support analytics that measure performance or detect errors.

In short, functional tracking focuses on making the core experience smoother and more reliable.

Targeting Tracking Technologies

Targeting tracking technologies enable advertising, retargeting, and marketing personalization. They collect browsing behavior and interactions to build user profiles, such as tracking which sites a user visits to serve relevant ads, measuring ad performance with social media pixels, or using third-party cookies for retargeting campaigns.

In short, targeting tracking focuses on profiling users to deliver personalized marketing and advertising.

Configurable flags for managing cookie preferences

The Rokt Web SDK provides two configurable flags for managing consent preferences:

• noFunctional: Controls the use of browser identifiers for functional tracking.
• noTargeting: Controls the use of browser identifiers for targeting tracking.

Both flags align with terminology used by common Consent Management Platforms (CMPs) for ease of implementation.

Web SDK localStorage keys

The Rokt Web SDK may write the following values to browser localStorage. Keys marked "Your page" are stored on your site. Keys marked "Rokt iframe" are stored under the domain the Rokt iframe loads from: Rokt's domain by default, or your own subdomain if you use a first-party domain. In key names, <accountId> stands for your Rokt account ID. If the ID contains an underscore, the SDK uses only the part before the first one.

Key	Stored in	Purpose	Not written when
RoktEventData	Rokt iframe	Stores real-time event metadata and event-occurrence state for the active SDK session so Rokt can process interactions and include relevant event state in subsequent SDK requests.	noFunctional: true
RoktEventDataTimestamp	Rokt iframe	Stores the timestamp for the latest RoktEventData update.	noFunctional: true
RoktRecogniser	Your page	Stores the browser recognition identifier that allows Rokt to recognize a returning user and persist user identity between page loads.	noFunctional: true
RoktRecogniser	Rokt iframe	Stores a browser identifier for the domain the Rokt iframe loads from. When that is Rokt's domain, it lets Rokt recognize the browser across sites on the Rokt network.	noTargeting: true
RoktRecogniser	Rokt's domain (first-party domain only)	Lets Rokt recognize the browser across sites on the Rokt network.	noFunctional: true and noTargeting: true together
RoktEtag	Rokt iframe	Stores the entity tag used to validate the cached recognition record for the browser.	noTargeting: true
RoktSessionId-<accountId>	Your page	Stores the Rokt session ID, session token, and expiry time, so the session continues across page loads. The SDK treats it as expired 30 minutes after the last session update. Most accounts keep this in a cookie instead (see below).	noFunctional: true
RoktPreselectRoutingBucket	Your page	A random number shared by the tabs of your site, so they get the same sampling decision for loading offers early. It expires 30 minutes after its last use.	noFunctional: true
RoktPreselectProducer	Rokt iframe	Marks the latest early offer request that stored offers, so Rokt can tell why a later page found no early offer. It holds a partial hash of the Rokt session ID, not the ID itself, and expires within 24 hours.	noFunctional: true or noTargeting: true

The Web SDK also sets RoktRecogniser as a cookie in each place the table lists. The cookie is SameSite=Lax on your page and SameSite=None in the Rokt iframe and on Rokt's domain. The same flags stop the cookie and the localStorage value.

For most accounts, the Web SDK keeps RoktSessionId-<accountId> in a SameSite=Strict cookie on your page instead of in localStorage. The cookie expires 30 minutes after the last session update. noFunctional: true stops it too.

Web SDK sessionStorage keys

The Rokt Web SDK may also write the following values to browser sessionStorage. The browser removes them when the tab closes. The Stored in column uses the same labels as the localStorage table. In key names, <sessionId> stands for the Rokt session ID.

Key	Stored in	Purpose	Not written when
rokt_session_id-<accountId>	Rokt iframe	Stores the Rokt session ID, so the session continues across pages in the tab.	noTargeting: true
rokt_session_timestamp-<accountId>	Rokt iframe	Stores when the Rokt session was last updated.	noTargeting: true
rokt_session_source-<accountId>	Rokt iframe	Records where the SDK found the session ID, such as a cookie on your page or a Rokt response.	noTargeting: true
<sessionId>_is_test	Rokt iframe	Records whether the session is a test session.	noTargeting: true
RoktSessionIdToken	Rokt iframe	Stores the session token for each Rokt session ID.	noTargeting: true
RoktTransactionsEventCache	Rokt iframe	Stores up to 50 recent events for up to 30 minutes, so Rokt can use them for offers.	noFunctional: true
RoktTransactionsPendingEvents	Rokt iframe	Stores up to 10 event requests that are waiting to be sent, for up to 30 minutes, so a later page can send them.	noFunctional: true
RoktTransactionsTokens	Rokt iframe	Stores the session tokens that authenticate offer and event requests. Each token expires 30 minutes after its last use.	noFunctional: true
RoktGwpReward	Rokt iframe	Stores the coupon code, PIN, and Rokt click ID for a Gift with Purchase reward, for up to 90 minutes. The SDK writes it only for offers that hand off a reward.	noFunctional: true
roktTabGeneration	Your page	Counts how many times Rokt placements have loaded in this tab.	noFunctional: true
roktPriorPageInstanceGuid	Your page	Stores the ID of the last page view the SDK recorded in this tab.	noFunctional: true
roktPriorLifecycle	Your page	Stores the latest lifecycle change of your page, such as hidden or visible, and when it happened.	noFunctional: true

Web SDK sessionStorage keys for loading offers early

When Rokt loads offers early for your account, the Rokt Web SDK may write the following values to browser sessionStorage. The browser removes them when the tab closes. The Stored in column uses the same labels as the localStorage table.

Key	Stored in	Purpose	Not written when
RoktPreselectRoutingBucket	Your page	A random number for the tab, so every page in the tab gets the same sampling decision for loading offers early.	noFunctional: true
RoktPreselectCache	Rokt iframe	One offer response loaded before the confirmation page, so offers show sooner, kept here instead of localStorage when noTargeting: true is set or the browser does not accept the localStorage write. It also holds the Rokt session ID and session token it was loaded with, your Rokt account ID, the page identifier it was loaded for (or the full page address, including any query string, when no identifier is set), the consent flags in effect, and one-way hashes (SHA-256) of the page attributes it was matched on, which can include the customer's email address and name. It expires with the Rokt session.	noFunctional: true
RoktPreselectInflight	Rokt iframe	The start time, send status, and page-close time of up to five early offer requests, used to count requests lost when the page navigates away.	noFunctional: true
RoktPreselectTabId	Rokt iframe	A random ID for the tab, so RoktPreselectProducer can tell this tab from your site's other tabs.	noFunctional: true or noTargeting: true

Web SDK localStorage keys for loading offers early

When Rokt loads offers early for your account, the Rokt Web SDK may also write the following values to browser localStorage, so a confirmation page in any tab of your site can use an offer loaded in another tab. Unlike the sessionStorage keys above, they stay after the tab closes. Each one expires as described below, and an expired one is removed or replaced the next time the Rokt Web SDK loads on your site. "Your page" and "Rokt iframe" mean the same as above.

Key	Stored in	Purpose	Not written when
RoktPreselectRoutingBucket	Your page	A copy of a tab's random number from the table above, so a tab opened while it is current gets the same sampling decision for loading offers early. A tab keeps its own number and writes it here again each time the Rokt Web SDK loads in it. It expires 30 minutes after it was last written.	noFunctional: true
RoktPreselectCache	Rokt iframe	One offer response loaded before the confirmation page, so offers show sooner in whichever tab reaches the confirmation page. It also holds the Rokt session ID and session token it was loaded with, your Rokt account ID, the page identifier it was loaded for (or the full page address, including any query string, when no identifier is set), the consent flags in effect, and one-way hashes (SHA-256) of the page attributes it was matched on, which can include the customer's email address and name. It is removed when it is used and expires with the Rokt session.	noFunctional: true or noTargeting: true
RoktPreselectProducer	Rokt iframe	Which tab last loaded an offer early, used to count offers loaded in a different tab from the confirmation page. It holds a shortened one-way hash of the Rokt session ID (never the ID itself), random IDs for the page and the tab, and the time. It expires with the offer it describes, or after 24 hours if that is sooner.	noFunctional: true or noTargeting: true

noFunctional: true

• Prevents the use or creation of browser identifiers for functional tracking.
• Existing identifiers on your page, such as RoktRecogniser and RoktSessionId-<accountId>, are ignored but not removed. The SDK removes the other stored values that noFunctional stops, such as RoktEventData and the keys for loading offers early.
• User identity is not established automatically. Without browser identifiers, the SDK cannot recognize returning users or persist user identity between page load. To enable user recognition and take full advantage of personalization, pass user identifiers (e.g. email, device ID) at initialization or call mParticle.Identity.identify() at the appropriate point in your flow. Note that for single page applications, this would only need to be done once, but for multi-page applications (or whenever the SDK is re-loaded), you would have to re-identify.
• If no identifiers are provided, the session is treated as anonymous for that visit.
• Targeting identifiers, including the Rokt iframe RoktRecogniser and RoktEtag, remain active unless noTargeting is also set.

noTargeting: true

• Prevents the use of browser identifiers for targeting tracking.
• Cross-site personalization and advertising identifiers are disabled. If you use a first-party domain, the Web SDK still writes a RoktRecogniser on Rokt's domain and sends it to Rokt, unless noFunctional is also set.
• The mParticle Web SDK skips the Rokt cookie sync. This flag does not stop cookie syncs that you set up for other partners in mParticle.
• The mParticle Web SDK tags the user profile with $NoTargeting, and Rokt keeps profiles with this tag out of its retargeting audiences.
• Functional identifiers remain active unless noFunctional is also set.

If a flag is omitted, set to false, or given any other value, the SDK will use identifiers as configured.

Behavior Comparison

Flag Configuration	Functional Tracking	Targeting Tracking	Other Identifiers (e.g. email, phone)
Default (no flags / false)	Browser identifiers are generated, stored, and used to enable personalization and checkout features (e.g. Upsells).	Browser identifiers may be used for personalization across sites (when applicable).	Always accepted if provided.
noFunctional: true	Functional browser identifiers, including the RoktRecogniser on your page, are not generated or used. If already present, they are ignored for this session.	Targeting tracking behaves according to the noTargeting flag (default is enabled), so the Rokt iframe RoktRecogniser and RoktEtag are still written.	Always accepted if provided.
noTargeting: true	Functional tracking operates normally (unless noFunctional is also set).	Browser identifiers are not used for targeting or cross-site personalization. If you use a first-party domain, the Web SDK still writes a RoktRecogniser on Rokt's domain and sends it to Rokt, unless noFunctional is also set.	Always accepted if provided. The user profile is tagged $NoTargeting and kept out of retargeting audiences.
noFunctional: true and noTargeting: true	Browser identifiers are not generated or used for functional purposes.	Browser identifiers are not used for targeting across sites.	Always accepted if provided. The user profile is tagged $NoTargeting and kept out of retargeting audiences.

Example

To set the noFunctional or noTargeting flags, include the following within your SDK initialization script:

window.mParticle.config.launcherOptions = {
    noFunctional: true, // Disables functional tracking
    noTargeting: true,  // Disables targeting tracking
};

note

These flags control browser-based identifiers. You can still pass other identifiers, such as email addresses or phone numbers, and Rokt uses them in accordance with your configuration. When noTargeting is set, the mParticle Web SDK also tags the user profile with $NoTargeting, and Rokt keeps it out of retargeting audiences.