What the barua pixel collects, what never leaves the visitor's browser, how long anything is kept, and how to be erased. Written for the owner of a site that runs barua, and plain enough for anyone who visited one.
barua records a masked replay of each visit so it can understand what a person was doing. In the replay, every input value and every piece of rendered text is replaced in the browser, before anything is sent.
One narrow edge to know about: a stylesheet loaded from another domain without CORS can render text out of your markup's attributes, and the browser will not let the pixel read that stylesheet to learn which attributes it uses. The pixel masks known text-carrying attributes and anything shaped like prose regardless; if your site uses such a stylesheet, keep personal data out of custom attributes.
The server double-checks its own bookkeeping too. When it cannot confirm which style rules applied to a stored piece of replay, it re-masks that piece fully instead of trusting the narrower first pass. If a re-mask attempt fails, the failure is recorded and retried on later visits. Whatever still cannot be repaired is removed with the replay itself: most of it on the normal thirty-day expiry, and the rare piece the bookkeeping cannot reach gets flagged for our operators to remove by hand.
Alongside the replay, the pixel sends plain events that name what was interacted with (a clicked control's label, capped at 80 characters) and what the page was about (the page's title, or a product's name with its price); those labels come from the page itself. Cart and order events a site publishes through its dataLayer travel with identity fields stripped and a 4KB cap (an oversized payload is reduced to its totals). Two things a visitor types do travel: the query when they use the site's search (read from the URL, capped at 120 characters), and the contact details covered in the next section.
An iframe's contents are never recorded, and an element the site marks with
data-cg-block gets the same treatment: the replay keeps only an empty
placeholder (the element's tag, class, width, and height). URL
parameters whose names mark them as credentials or as typed
content (an access token, an email a form wrote into the address) are scrubbed out, in the
query string and in the fragment. Each scrubbing rule applies from the day it ships. Replays
stored under earlier rules age out on their own within 30 days; older activity-log rows keep
what they arrived with for as long as the store keeps its log.
Location is resolved to city level at the network edge. The visitor's IP address is never stored. Script error messages travel as the page's own code emits them, trimmed to 200 characters with emails and long numbers redacted first; an error that quotes what someone typed can carry that text.
Contact details a visitor is actively giving the site are captured in the clear: the email in a newsletter popup, the name on a checkout form. barua picks them up only at the moment the form or popup actually sends, whether the visitor clicks its button or presses Enter. Typing alone never counts as an identity. The same handover happens when the site already holds the details and passes them through its dataLayer, the way shop platforms announce a signed-in customer.
A site that wants none of this automatic pickup puts data-auto-identify="off" on
its tag, and barua then only learns an email when the site passes it explicitly.
No cookies. The pixel keeps six small values in the browser's localStorage, all scoped to the one site:
| Key | What it holds |
|---|---|
cg_aid | an anonymous id for this browser, on this site only |
cg_sid | the current session's id |
cg_last | when the session was last active; after 30 quiet minutes the next activity starts a new one |
cg_consent | the visitor's consent answer |
cg_first_touch | how they first arrived: the referrer, the landing path, campaign parameters, and when |
cg_geo_sid | a note that the city lookup already ran this session |
One more value can appear briefly in sessionStorage: cg_sblk, written when a
search form the site marked with data-cg-block submits, so the results page knows
to keep that search private too. It holds the name of the search field and a timestamp, never
what was typed; the next page reads and clears it, and if no navigation happens it is
cleared within seconds.
On a site running consent-required mode, none of these are written before the visitor
answers. A refusal writes exactly one, cg_consent, so the refusal itself is
remembered, and a withdrawal after an earlier yes clears the rest.
Two modes. By default the pixel runs from the first pageview. With
data-consent="required" on the tag, it captures nothing and writes nothing to the
device until the site's consent banner calls barua.consent(true). One narrow
exception: if the site's own code calls barua.identify() before the answer, that
identity waits in memory, goes out only on a yes, and dies with the page otherwise. A
barua.consent(false) stops the recorder, clearing both the queue and the stored
values; the refusal marker is the one thing kept. When consent arrives, barua reads what the
page has already published (its dataLayer included) and starts from there. The grant also
restarts the activity clock at that moment: however long the page sat open before the visitor
answered the banner, the quiet wait does not count against the session, and another tab opened
right after joins it. A session left over from more than thirty quiet minutes is replaced with
a fresh one at the yes; a session still active within that window simply continues.
The install page shows the wiring.
Session replays expire after 30 days. What barua works from after that is the distilled profile it wrote, like "came back to the same jacket three times", plus the plain activity log (which pages, which products, when, for how long) for as long as the store keeps one. The profile is what decides whether an email would help.
Everything the pixel captures is stored in EU regions. Two moments reach outside that storage: deciding and writing an email passes the distilled profile through the AI model that does the thinking, and sending one hands the recipient's address and the message to our delivery provider, the way any email leaves any system. Neither step is pinned to the EU today. Profiles are built from one site alone, and nothing is shared with data brokers. What a visitor does elsewhere, barua never learns.
Every email barua sends has one-click unsubscribe, and unsubscribing sticks: nothing new starts after that moment, and an email already in the middle of being sent may still arrive, the way it does with any sender. There's also a hard floor between messages: barua never decides two for the same person within 20 hours (with longer cooldowns per kind of message), and it re-checks that gap at the moment of sending. Hearing from a site often means something is wrong, and we'd want to know: hello@barua.ai.
To have your data erased, ask the site you visited, or write us from the address in question. Erasure is keyed by email. An anonymous visitor's replays expire on their own after 30 days.
One record survives on purpose: the erased address goes on the suppression list, keeping that address off every future send from the site you asked. Each site keeps its own list, the same way each site keeps its own profiles. Short-lived operational traces that carry an address, like the record that spaces outgoing email, clear on their own within two days.