Platform

Technical reference

Everything the tag does in the visitor's browser and on the network, on one page: the single first-party cookie and the storage keys, how Safari and ad blockers change what is remembered, exactly what data reaches DynaMeet and where it is hosted, and the hostnames to allow in a CSP or firewall. Written so you can hand it to IT, legal or a customer as is.

Cookies & storage

Meeton sets exactly one cookie, and it is first-party: it lives on your domain, is written by the script you installed, and holds only a random visitor ID. This page lists everything the tag keeps in the browser, why, and for how long.

Where the visitor ID lives

Third-party cookie blocking only affects the right-hand jar, which is empty.

The ID is a UUID generated in the browser with crypto.randomUUID(). It is written to localStorage and to a cookie on the registrable domain (.example.co.jp, not www.example.co.jp), so a visitor who moves between your subdomains stays one visitor. Both copies are refreshed on every page view, and if one is missing it is restored from the other.

Everything the tag stores in the browser

What the cookie looks like

For a page at https://go.example.co.jp/pricing the loader writes, in effect:

dynameetVisitorId=3f9c1a2e-7b44-4d8e-9c1f-2a6b5e8d4f10; expires=+365 days; path=/; SameSite=Lax; domain=.example.co.jp

The registrable domain is computed with the Public Suffix List, so example.co.uk and example.github.io are handled correctly. On localhost no domain attribute is set. The cookie is not HttpOnly, because it is written by JavaScript on your page rather than by a server, and no DynaMeet server ever sets a cookie on your domain.

When storage is blocked

Safari's "Block all cookies", private windows and some enterprise policies make every storage call throw. The loader wraps each read and write: the ID is then held in memory for the current page only, chat, booking and forms all still work on that page, and the tag reports to us that storage was blocked so analytics can account for it. Nothing on your page is affected.

Describing it in your cookie policy

The cookie is a pseudonymous identifier used to recognise a returning visitor. Whether it needs consent depends on your jurisdiction and your own policy; your legal team decides. Customers who list it usually describe it like this:

Frequently asked

Browser behaviour

The widget works in every current browser on desktop and mobile. The differences are about memory, not function: Safari forgets a visitor after seven days of Safari use with no click on your site, private browsing forgets at the end of the page, and an ad blocker may hide the widget entirely. In every case your site keeps working exactly as before.

Browser matrix

Safari and Intelligent Tracking Prevention

Apple's ITP deletes all script-written storage, cookies and localStorage alike, once the visitor has used Safari for 7 days without clicking, tapping or typing on your site. Scrolling does not count, and nothing our script writes can reset that clock; only the visitor's own interaction does. This affects every vendor equally.

Two things the loader does to make the best of it:

• It rewrites the cookie on every page view, so the 7-day window always starts from the latest visit rather than the first.
• It keeps the localStorage copy and the cookie in sync, so a visitor who clears one but not the other is still recognised.

What you will see in reports: a Safari visitor who returns after more than a week appears as a new visitor. Once they identify themselves again, in chat, a booking or a form, the two records are linked to the same contact.

Phones

The widget is designed and measured on iPhone and Android. It adapts to the on-screen keyboard, respects viewport-fit=cover safe areas, and the same single first-party cookie applies. Every browser on iOS is WebKit, so Chrome on an iPhone behaves as Safari does, including ITP.

Ad blockers and corporate networks

Your visitors are on their own networks, so a filtered network usually only matters for your own staff on the office network or VPN, which is where demos and acceptance testing happen. If the widget does not appear on a work machine:

1. Open the browser's Network tab and reload. If meeton.js is blocked or the request to api.dynameet.ai fails, a list is blocking it.
2. Allow-list app.dynameet.ai, api.dynameet.ai and api-ws.dynameet.ai in the blocker or proxy. See Domains & CSP for the full list.

Frequently asked

Data & security

From the visitor's browser we receive the pages they view, where they came from, their browser and language, and, only if they engage, their chat messages, bookings, downloads and the contact details they type into your forms. Everything travels over encrypted connections to DynaMeet, and nowhere else, and is stored encrypted in Japan.

How data flows

Two outbound connections from the visitor's browser, both encrypted. Nothing connects to your servers.

What we receive

What we do not collect

• No screen recording or session replay of visitors.
• No keystrokes outside the recognised contact fields above; passwords and payment fields are never read.
• No data from other websites. The cookie is first-party and the ID is meaningless elsewhere.
• No third-party scripts, unless you configure LinkedIn conversion tracking, in which case LinkedIn's own tag is loaded.

Hosting and AI processing

The service and all stored customer data live in the Amazon Web Services Tokyo region (ap-northeast-1). One exception to name: AI responses are generated by Google Gemini, and those requests may be processed by Google outside Japan. The DPA, the sub-processor list and the security whitepaper are published at dynameet.ai/en/security.

Each team has a Data & Privacy setting. When it is on, anonymised, statistically processed data may be used to improve the product, which may include AI models, as the Terms of Service describe. Turning it off applies going forward and changes nothing about how the product works for that team.

How the form watcher behaves

The tag watches the forms already on your pages for recognised contact fields, so a visitor who fills in your contact form becomes a known contact without a second form.

• A value is sent when the visitor leaves the field, not on submit, and held as a staged record.
• It becomes a contact only once the submission is confirmed: your CRM receiving it, a HubSpot success message or redirect, or a thank-you page. An unconfirmed record expires.
• Fields it does not recognise are ignored. It stops reading once the visitor is identified.

Security policies

Frequently asked

Domains & CSP

Everything is outbound from the visitor's browser; nothing connects inbound to your network and nothing is installed on your servers. If your site uses a Content Security Policy, allow three DynaMeet hostnames. A corporate firewall or proxy your own staff browse through needs those three plus one more.

Our hostnames

Ready to paste into a CSP

Add these sources to the directives you already have. If your policy has no frame-src, browsers fall back to child-src and then default-src, so make sure one of them allows the frame.

script-src  https://app.dynameet.ai;
frame-src   https://app.dynameet.ai;
connect-src https://api.dynameet.ai wss://api-ws.dynameet.ai;

The inline config line (window.DynaMeetConfig = …) is an inline script. If your CSP forbids inline scripts, either give it a nonce like your other inline snippets, or move the assignment into a file you already serve.

<script nonce="{{nonce}}">window.DynaMeetConfig = { teamId: "YOUR_TEAM_ID" };</script>
<script async defer src="https://app.dynameet.ai/meeton.js"></script>

Firewalls and proxies

Usually your firewall does not matter: your visitors are on their own networks. It matters only for people browsing through a filtered network, typically your own staff on the office network or VPN, which is where your demo and acceptance testing happen. Allow the three hostnames above plus the S3 host for Library files.

• WebSockets blocked. The widget still loads and chat still works over HTTPS; only the live push of new messages falls back to the next page view. Allowing wss://api-ws.dynameet.ai restores it.
• Inbound. Nothing. The tag's connections are all outbound from the visitor's browser to DynaMeet; nothing reaches your servers.
• The one thing that reads your site is the AI knowledge-base crawl, if you enable it under Chat → Knowledge. It fetches your public pages over ordinary HTTPS like a visitor would, so a bot block or geo block on your site can refuse it.

Frequently asked