Server-Side Click ID Storage

An alternative to storing the cjevent in the browser as a cookie is storing it on the advertiser's server at the time of click.

📘

Important distinction: This is different from CJ's offline conversion reporting methods (GraphQL API, S2S webhook, SFTP offline data file). Those determine how conversion data is sent to CJ. Server-side click ID storage determines where the click ID is kept between click and conversion.

How It Works

• At click time, the advertiser's application reads the cjevent from the landing page URL and saves it server-side (session, database, or order record).
• At conversion time, the server retrieves the stored cjevent and includes it when reporting the conversion to CJ.

Not affected by:

• Cookie expiration or deletion
• JavaScript execution timing
• Browser privacy restrictions (ITP, ETP, ad blockers)
• Consent management that blocks client-side scripts

What It Does Not Solve

• The cjevent must still arrive in the landing page URL. If redirects strip query parameters before the server reads the value, server-side storage fails for the same reason cookies fail.
• Requires development work: reading the cjevent from inbound URLs, associating it with the consumer's session or order, persisting it through the purchase flow, and including it when reporting conversions.

When It Is Worth the Investment

• A meaningful share of traffic comes from Safari or Firefox (shorter cookie lifespans).
• Your purchase cycle is long (days or weeks), increasing cookie expiration risk.
• Your site serves regions with consent requirements that delay or prevent client-side cookie writes.
• Your team wants to reduce dependency on browser-based storage as cookie restrictions tighten.