What ARCY collects

ARCY runs inside your Product. Below is what arcy.js sends while it runs, so you can answer a data-inventory question and fill in your own privacy policy from it. This is the technical inventory, not the legal Privacy Policy; for the binding document, including your data-subject rights and our Children's Privacy stance, see arcyai.com/privacy.

Before consent

arcy.js measures the page before anyone has answered your banner, and it never measures the person. From every page load it sends the route, the referrer and campaign parameters, the browser, operating system and screen width band, and the interaction, form field, scroll and error events listed under Per session. It also sends three events about the chat itself: that the chat became visible on the page, that somebody opened it and where the open came from, and that it was closed, with how long it was open and whether a message was sent while it was. The chat asks for consent inside itself the first time it opens, which is why these three are measured here as well, and none of them carries a word the visitor typed. No visitor id, session id or user id goes with any of this, and nothing is written to the device. Events from one page load share a random id that lives in memory and dies with the page. To count a day's visitors, and the people the chat was shown to, our server hashes a random daily value together with your environment, the IP address and the browser identity. The daily value is deleted when the day ends, so the hash can be neither reversed nor matched to another day, and the IP address is never stored. These events feed the three numbers of the last seven days on Home and the chat rates on Conversations, and nothing that describes a person; a later consent does not claim them. A browser that sends Do Not Track or Global Privacy Control is not measured at all.

Everything below is written to the browser or sent to ARCY only after the visitor has consented. The consent model and the cookies are on Consent.

Per session

• Session start and end timestamps, and when the tab was switched away from and back. These are timestamps only, and they are what keeps "time in product" honest.
• The route a session began on, and each route change, with ids replaced and every query value dropped.
• Session context, captured once: where the visitor arrived from, campaign parameters in the address, browser and operating system, and a screen width band such as phone or laptop. Never exact screen dimensions, never a precise location, and no IP address kept as an identifier.
• The arcy.js version the page runs, and from 0.2.9 whether it came from the pasted script or the npm package, sent at every session start so we can tell which release is live. It describes our code, not the visitor.
• The browser's time zone, such as Europe/Istanbul, sent at session start from arcy.js 0.1.18 and stored on the session, so time of use is read in the visitor's own clock. Never sent before consent, cleared when the visitor refuses, and it does not locate the person.
• Interaction events: clicks on interactive elements, navigations and form submits, described structurally by element type, position and label, never by value, and whether the page changed after a click, so the Activity page can mark a click that did nothing. A field or a dropdown is named by its aria-label, its attached <label>, aria-labelledby, placeholder or name, never by what it shows. A form submit also carries the label of the button that sent it, so a form with no name of its own can still be told apart. This is how a flow step finds its target without you annotating your source code.
• Form field events: which field a person opened, filled or emptied again, with the field's type, whether it already held a value when they arrived (yes or no, never what the value was), whether the browser accepted the entry, and the structure of the field's own form, described the same way as an interaction element with the form's text left out, so ARCY can tell which form a field belongs to. A fill is reported when the person commits a value or leaves the field, not on the first keystroke. Never the value typed, and never its length.
• Scroll depth as four milestones per page. Never a continuous position and never a heatmap.
• Errors: an uncaught error on the page, with its message and the script it came from, and a request that returned an error status, with its method, that status and a scrubbed URL.
• Flow events: a flow starting, each step reached and completed, the flow finishing or being left, and a step that could not run, with its reason. Each carries how the run began: a pill, the flows list, an offer inside an answer, or an Experiment's trigger.
• Experiment trigger events: an offer shown on the page and an offer closed or taken, a Whisper or an Announcement tapped, an Announcement closed, an NPS score given and an NPS question passed over, each with the Experiment and trigger ids and nothing about the person beyond the session it happened in. Which triggers are live for a session, how many things ARCY started in the current visit and whether the person said no in it are held in the tab's own storage for the Frequency limit and die with the tab.
• Widget and agent events: the chat becoming visible, every open with where it came from, every close with how long the chat was open and whether a message was sent, each message sent and each answer given, an answer ARCY did not have, flows it suggested, cards clicked, a thumbs up or down, and a usage limit being hit. The message text is not on these events.
• The userId and the attributes you pass to identify(). Everything beyond the userId is optional; pass only the attributes you want ARCY to hold. A value that looks like a card number, a bank account number (IBAN) or an API key is refused before storage and never logged.
• The name of an event your own code reports with track(), and the name of an event your page already sends to an analytics tool you switched on under Integrations, recorded under the name you accepted there. Names only, never the event's properties.
• The page a visitor is on, only when the assistant reads it to answer a question: its headings and its button, link and field labels, never a field's value, and the page address without its query string. A # part is sent only when it is a route such as #/settings, and then without its own query.
• An answer typed into a flow step, only when the step has Save the answer as an attribute set; it is then held as that attribute, under the same payment data refusal. Any other typed flow answer stays in the browser, apart from what a Request step sends to your own endpoint.
• A flow run's messages, its questions and the choices the visitor picked, stored with the conversation so you can read the run on Conversations. A typed answer, and any value your endpoint returned that the visitor did not pick, is replaced in the browser before the run is sent. Only kept while storing conversation text is on.
• Conversation text when a user talks to the agent or runs a flow, so the agent keeps context across a session and you can read the transcript. Storing it can be switched off, and what changes when you do is on How AI request content is handled.
• An answer to an Ask NPS Experiment: the score from 0 to 10, and the reason the visitor typed. The score is held against the person so their latest one can be targeted on and read as a band. The reason is message content, so it is kept only while storing conversation text is on; with it off the score is still kept and the reason reads as masked. One person is asked at most once every 90 days across the Product, and forgetting a person deletes their answers with everything else of theirs (Data retention).

What a connected agent can read

A coding agent you connect on ARCY MCP reads how a Product is set up: its Specialists and their Experiments, Insights, flows, endpoints, attributes and events. It cannot read what your visitors did unless an Admin turns on Let a connected agent read visitor behaviour, which is off until they do and records who turned it on and when.

Once it is on, the agent can also read where sessions ended, where people struggled, how a group's rate differs from the rest, how an Experiment is performing, and the session traces behind those places, so it can propose Specialists and Experiments from what people actually do. Turning it off stops those reads at once.

Two limits hold either way. An attribute whose AI can read this value is off is never sent, the same rule that applies to our own models. And the agent only ever drafts: publishing stays yours, on the page that owns the draft.

The agent runs on your side, so what it reads reaches whichever model you run it with. That is your choice of processor, not ours, and the switch is where you make it.

Masked before anything leaves the browser

Input and hidden field values, and any label matching an email, a national id or a payment card pattern, are masked client-side before an event is sent. What ARCY receives is the shape of an interaction: the kind of element, roughly where, and what it is labelled.

How a failed request is seen

A browser offers no other way to read an HTTP status, so arcy.js wraps fetch and XMLHttpRequest.send on your page. The wrapper calls your original function first and reports afterwards. It never reads a response body, so what your code receives is the object the browser made. If the wrapper cannot install, your original function stays in place. No request or response body, header or payload is collected; an event carries the method, the status and a URL scrubbed like a route.

Never collected

• No value a user types into your Product's own fields, and not its length either. A rich-text editor or any editable area counts as a field: its text is treated as a value and only its label is sent.
• No session recording and no replay. A session trace is an ordered list of events, not a reconstruction of the screen.
• No DOM snapshot. A copy of your page never reaches us.
• No keystroke capture, no mouse movement, no cursor position and no hover. Where a person struggled is read from clicks, form fields and stops between events.
• No email address, password or form value you did not pass yourself as an attribute.
• No card number, bank account number (IBAN) or API key, by any path: identify(), a flow's saved answer and an Import all refuse a value that looks like one, and no attribute may be named for a card, a security code, a PIN, a password or an IBAN (Attributes).

How long each of these is kept is on Data retention.