Skip to content
Decision engineAnalyticsSovereigntyPricingJourneysDocs
FA
Sign inRequest a demo
Decision engineAnalyticsSovereigntyPricingJourneysDocsSign in
FA
Request a demo

Cookie and Browser Storage Policy

Version 1.0 · published 13 August 2026

What this document is

Most cookie policies are copied from one another and are wrong about the product they describe. This document says exactly what Segmentic writes into a browser, where it writes it, and how long it stays there.

The most important fact comes first. The Segmentic web SDK writes no cookies, not a single one. Everything it needs goes into the browser's local storage (`localStorage`) on the same domain the script is loaded on, plus one entry in the browser's cache storage (`Cache Storage`) for web push.

The only real cookies belong to the Segmentic dashboard itself: the login session cookie and the language cookie. Somebody who never signs in to the dashboard never receives a cookie from us.

That is why this document is called browser storage and not just cookies. A title that said only "cookies" would describe something that does not exist and stay silent about the thing that does.

Article 1Everything that is written into the browser

This list is complete. If you find a key in a browser that is not here, it is not ours.

NameWhereWhat forHow long
`segmentic_anonymous_id`local storage, customer domainRandom identifier for an anonymous visitor, so one person's events stay togetherNo expiry. Changes when site data is cleared, or on logout
`segmentic_user_id`local storage, customer domainThe identifier the customer itself assigns to a known userUntil logout
`segmentic_session`local storage, customer domainSession identifier, for visit length and funnel windowsRenewed after 30 minutes of inactivity
`segmentic_queue`local storage, customer domainEvents not yet sent, so closing a tab does not lose themUntil sent successfully
`segmentic_campaign`local storage, customer domainThe last message a visit came from, for purchase attribution7 days
`segmentic_traits`local storage, customer domainTraits from the last `identify` call, for targeting on-site messagesUntil logout
`segmentic_opt_out`local storage, customer domainA marker that the visitor opted out of collectionUntil the visitor reverses it. Not cleared on logout
`segmentic_seen`local storage, customer domainThat this browser has been here before, to tell a new visitor from a returning oneNo expiry. Deliberately not cleared on logout
`segmentic-config`cache storage, customer domainThe settings the push service worker reads: service address, public write key, public push key, user identifierUntil push is unsubscribed or site data is cleared
`__Host-segmentic_session`cookie, Segmentic dashboard domainLogin session of a dashboard user, carrying the HttpOnly, Secure and SameSite=Lax flagsUntil logout or session expiry
`NEXT_LOCALE`cookie, Segmentic dashboard domainThe language the dashboard user choseUntil the user changes it
`app_mode`, `app_palette`, `app_paradigm`local storage, Segmentic dashboard domainThe theme, colour and layout the dashboard user choseUntil site data is cleared

تبصره 1: the write key held in `segmentic-config` is public from the outset and is visible in the page's own script tag, so storing it discloses nothing. No other secret is written into the browser.

تبصره 2: on an installation without HTTPS the session cookie carries no prefix and is named `segmentic_session`. The `__Host-` prefix only has meaning over HTTPS.

Article 2Why the SDK writes no cookies

A cookie travels with every request to that domain, whether it is needed or not, and it can be scoped to a parent domain so that subdomains see it too. Local storage does neither: it is bound to one origin, it is never sent anywhere automatically, and only the script on that page can read it.

A measurement tool that has nothing to say on every request gets nothing but cost out of a cookie. So writing no cookies here is a technical decision rather than a privacy pose.

The consequence that matters more to a visitor: there are no third-party cookies at all. The keys are written on the customer's own domain and the browser does not let another site read them. Somebody who visits two of our customers' sites receives two unrelated anonymous identifiers. Each customer's data stays in that customer's account and no cross-customer profile is built.

Article 3Expiry, as it actually works

A cookie has an expiry date and the browser enforces it itself. Local storage has no such thing. Whatever is written there stays until somebody clears it, even for years.

So every number in the "How long" column above is a rule in our code, not a guarantee from the browser. We write that distinction out deliberately, because saying "7 days" without it is a claim the browser does not stand behind.

There are three real lifetimes, and all three are enforced at the application level:

  • **Session renewal on inactivity.** The session identifier is renewed after 30

minutes of inactivity, not on every page load. Somebody who reads an article for ten minutes and then clicks stays inside one session.

  • **Campaign attribution window, 7 days.** After that, a visit is no longer

attributed to the message that brought the person in. The same number exists on the server side, and two different numbers would mean reports that disagree with each other.

  • **Logout.** The user identifier, the session and the campaign attribution are

cleared and a fresh anonymous identifier is created. The reason is the shared computer: the next person's purchase must not be credited to a message the previous person received.

تبصره 3: `segmentic_seen` is the only key that survives logout. Logging out does not turn somebody into a new visitor, and clearing that marker would make the new-versus-returning numbers wrong. We say so here so that nobody has to discover it later.

تبصره 4: if local storage is unavailable (Safari private browsing, a locked-down corporate browser, or an exhausted quota), the SDK falls back to in-memory storage and none of these keys survive closing the tab.

Article 4What is not in the browser but the server keeps

A browser storage document that talks only about the browser is misleading. So, also:

  • The raw IP address is stored on every event.
  • The raw User-Agent is **not** stored on events. Three columns are derived

from it, browser, operating system and device type, and the raw string is discarded.

  • The exception to that rule: on a web push subscription the raw User-Agent is

kept, because without it there is no way to tell which browser a subscription belongs to.

  • All of this data is stored inside Iran.

We state no default retention period, because there is none. Retention in the system defaults to zero, and zero means "keep until the customer decides". Each customer configures retention and erasure for its own account, and both are built.

Article 5We show no cookie consent banner, and why

No published Iranian regulation was found that requires separate consent for writing a cookie or reading browser storage, the way the European rules do. Iran's Executive Directive on Improving the Protection of User Privacy, approved in 1402 of the Iranian calendar, requires transparency and explicit consent, but its text is about the collection, processing and storage of user information and it does not address the technical mechanism of storage inside a browser. How that directive applies to a service like ours, which has no direct relationship with the end user, is still unclear and in our view needs legal advice.

So our position is this: the right place for consent is where the customer faces its own user, meaning the customer's own signup flow and the customer's own privacy policy. Segmentic injects no banner into a customer's site, because the site is not ours.

This is a product decision and not a legal claim. If a rule on the point is enacted, both the product behaviour and this document will change.

Article 6How a visitor stops all of this

Four ways, and all four are real:

  • **Clearing site data.** In the browser settings, every key above goes at

once. Next time a fresh anonymous identifier is created, which means earlier behaviour is not joined to the new visit.

  • **The Do Not Track signal.** If the browser sends it, the SDK collects no

events by default. A customer can switch that default off in the SDK configuration, and from then on the responsibility is the customer's. We say so here too, so that this document is complete.

  • **Opting out from inside the customer's site.** The `optOut` call stops

collection and discards the queue that has not been sent yet, rather than only stopping what would come next. An opt-out that quietly delivers what was already collected is not an opt-out.

  • **Turning local storage off in the browser.** The SDK falls back to in-memory

storage and everything goes when the tab closes. The customer's site does not break either, because every storage access is guarded.

Opting out of receiving messages is a separate matter, and a preference and unsubscribe centre is built for it.

Article 7This script sits on the customer's site

The SDK runs on the customer's own domain, with the customer's own write key, and the customer decides which pages carry it. Three things follow:

  • Informing the visitor is the customer's duty. The customer's privacy policy

needs this table or its equivalent, and the customer is free to take the rows verbatim.

  • Segmentic has no direct relationship with the visitor and knows nothing about

that person beyond what the customer sent.

  • An access or erasure request from a visitor goes to the customer first. If

one reaches us directly we refer it to the customer, and we do not touch the customer's data without the customer's instruction.

تبصره 5: per-customer erasure is built and is not waiting on any new technical decision. When a customer instructs an erasure, it runs.

Article 8Changes to this document

Any change to this document is announced at least 60 days before it takes effect. If a change adds a key to the table or lengthens the life of an existing key, the announcement says which one changed.

The table above was written from the SDK itself, and this document is worth something only for as long as it matches the code.

A note on language

This is a translation. The Persian version of this document is the authoritative one, and where the two differ the Persian text prevails. The document is governed by Iranian law, and an English text that could be argued to mean something else would serve nobody.

Contact

Questions or requests about data: privacy@segmentic.net

Support: support@segmentic.net

Kargostaran Nasl Javan Bakhtar https://segmentic.net

Segmentic

Segment down to one person

Product

  • Decision engine
  • Impact analysis
  • Reports and analytics
  • Platform core
  • Data sovereignty
  • Journey canvas
  • Frequently asked questions

Company

  • Migration and pricing
  • Request a demo
  • Sign in to the panel
  • Service status

Legal

  • Terms of use
  • Privacy
  • Messaging policy
  • Security
  • Cookies
  • Service level
  • Trial terms
  • Cancellation and refunds
  • API versioning

Guides

  • Data residency and on-premise
  • Running under sanctions
  • Integration questions
  • Push without Play Services

Platform comparisons

  • All comparisons
  • Segmentic vs AdTrace
  • Segmentic vs Zebline
  • Segmentic vs Metrix
  • Segmentic vs Braze
  • Segmentic vs CleverTap
  • Segmentic vs MoEngage
  • Segmentic and an SMS gateway
  • Segmentic and a loyalty club
  • Segmentic and a CRM
  • Segmentic vs WebEngage
Phone
02182803208
Address
قم، پردیسان، پارک علم و فناوری قم، شرکت سگمنتیک
Email
sales@segmentic.net
Registration number
21522
نماد اعتماد الکترونیکی
© 2026 Segmenticفارسی