Privacy Policy
Effective July 29, 2026 · last updated October 16, 2026
This policy covers both the DMC Pilot website and the DMC Pilot platform. It is written to be useful to two different readers: a person whose data we hold, and a data protection officer at a destination management company deciding whether to put their attendees' data into our software. The distinction that matters most is set out first.
Our two roles
Digital Envision LLC (“DMC Pilot”, “we”, “us”) handles personal data in two distinct capacities, and which one applies changes who decides what happens to the data.
As a controller, for data about our own prospects, customers and the people who use our software: your account, your name and work email, billing contacts, website inquiries and support correspondence. Here we decide the purposes and means of processing, and this policy governs it directly.
As a processor, for the operational data a customer puts into the platform: their programs, their corporate clients, their attendees and delegates, their vendors and their documents. Here the customer, the destination management company, is the controller. They decide what to collect, why, and for how long. We process it on their documented instructions under our Data Processing Addendum, and we do not use it for our own purposes.
The practical consequence for an attendee: if you attended an event and want to know what is held about you, the organization that invited you is the controller and the right place to ask. We will help them answer, but we cannot lawfully hand their records to a third party on request, and we will not.
Data we hold as controller
Website visitors
The website uses Vercel Web Analytics to count page views and a small number of interactions, such as which call to action was used. It sets no cookies and does not track you across other websites. Visitors are counted using a hash derived from the request, which is discarded within 24 hours, and page views are stored as aggregates rather than against a person or an IP address.
The website also uses Google Analytics. It sets cookies only if you accept them in the banner on your first visit; until then it uses none. See the Google Analytics section of the Cookie Notice.
What you type is never sent to analytics. When the contact form is submitted we record only whether it succeeded or failed, never your name, email, company or the content of your message. Those reach us by email and go nowhere else. See our Cookie Notice for the complete position, including the booking calendar.
Inquiries and demonstrations
When you request a demonstration or contact us we collect your name, work email, company and whatever you choose to tell us, and we use it to respond, to hold the meeting and to follow up about the product. If you book a call, the calendar is operated by Cal.com and your booking details go to them as well as to us.
Account holders
Access to the platform is by invitation only; there is no open sign-up. For each user we hold a name, email address, role and permission set, authentication data including two-factor enrollment where enabled, and a record of significant actions taken in the product. We hold billing contact details for the organization, and Stripe holds the payment instrument. We never receive card numbers.
Data we process for customers
On our customers' instructions the platform stores, depending on which features they use: program and itinerary records; attendee and delegate names, contact details, companies and travel details including flight and passport-adjacent information; dietary requirements and allergies; signed waivers and consent records; vendor and supplier contacts; proposals, contracts and e-signature evidence including signer IP address and device; uploaded documents and photographs; internal messages; and staff timesheets.
Each customer's data is isolated at the database level using row-level security, so a record belongs to exactly one organization and that boundary cannot be bypassed by the application. Within an organization, access is governed by a permission model across fourteen product areas, and program access is membership-scoped: a colleague who is not on a program cannot reach it.
We do not sell this data, we do not use it to train artificial intelligence models, and we do not use it to build profiles or advertise to anyone.
Health and other sensitive data
Dietary requirements and allergies are special category data under Article 9 of the GDPR, meaning data concerning health. They are also sensitive personal information under the CPRA. We treat them accordingly, and more strictly than the rest:
- The platform refuses to store them without a recorded lawful basis. Before dietary or allergy data can be saved against a program, a named administrator must record which Article 9(2) condition applies, who collected the attendees' consent and where. An attempt to save health data without that on file is rejected, not warned about.
Two things worth knowing about how this works in practice. It is an attestation by the DMC rather than a tickbox shown to an attendee, because attendees never interact with this platform: the data reaches us from the DMC or from their client, so a checkbox here would record somebody consenting on the attendee's behalf, which is not consent at all. And the requirement applies to every program, not only those touching the EEA or the UK, because health information is a special or sensitive category under almost every modern privacy law, including the CPRA and the US state sensitive-data statutes. The operator is asked the question in plain language rather than in statutory citations; the citations live in this policy and in the Addendum, where they belong. - They are encrypted at rest with a dedicated key, separately from the database's own encryption, on every path that writes them.
- They carry the shortest retention period of any data class in the product: they are cleared 30 days after a program ends, a ceiling no setting can lengthen.
- They are excluded from the context routinely given to the AI assistant. Until 29 July 2026 they were included in the ambient program context on every assistant request; they are now reachable only through a specific attendee lookup, which records each access to the audit trail.
- Where a model call could carry them, it is restricted to zero-data-retention endpoints, which do not retain the request at all. If no such endpoint is available the request fails rather than being routed somewhere that would retain it.
The title and place of a medical incident logged on a program are also health data. They are sent to an AI provider only when a person with access to health details asks for a draft of that program's report summary, over a zero-data-retention endpoint, and each such request is recorded in the activity log.
We are not a covered entity or business associate under HIPAA and this data is not protected health information: it is collected to cater an event, not to provide or pay for healthcare. The GDPR obligations above are in some respects the stricter standard in any case.
Staff location and device data
Where a customer uses time tracking, staff check in and out from their own device and the platform records the location at check-in, together with the resolved address, IP address and browser user agent. This exists so that a DMC can evidence that a member of staff was where the program needed them, and so that hours can be verified.
It is not continuous tracking: a position is recorded at the moment of a check-in or check-out, and at no other time. It is retained for 90 days by default, and an employee's own copy of this data is included in the data export available to them. Because this is monitoring of workers, a DMC deploying it will usually have its own obligations: consultation, notice, and in the EEA very often a Data Protection Impact Assessment. Those sit with the customer as controller.
Lawful bases
| Processing | Basis |
|---|---|
| Operating the platform for a customer | Performance of our contract with the customer (Art 6(1)(b)) |
| Website analytics, cookieless and aggregate | Legitimate interests in understanding whether the site works (Art 6(1)(f)) |
| Google Analytics cookies on the website | Your consent, given in the cookie banner and withdrawable at any time (Art 6(1)(a)) |
| Responding to your inquiry or holding a demonstration | Legitimate interests, or steps prior to a contract (Art 6(1)(f), (b)) |
| Security, abuse prevention, rate limiting and audit logging | Legitimate interests in keeping the service and its data safe (Art 6(1)(f)) |
| Billing, tax and statutory records | Legal obligation (Art 6(1)(c)) |
| Attendee data, including dietary and allergy fields | Determined by the customer as controller. For Article 9 data the customer must identify a condition under Art 9(2). That is usually explicit consent from the attendee, obtained when they register. The platform now enforces this: see §4. |
Artificial intelligence
The platform includes AI features: an assistant that answers questions about your programs, document and manifest parsing, drafting help, and research on clients and destinations. These are worth being precise about, because “we use AI” tells you nothing about where your data goes.
- Nothing is used for training. Every model request is sent with data collection denied at the routing layer, which excludes providers that store or train on inputs, and the account-level settings with our model gateway independently exclude every endpoint that trains on requests.
- Requests carrying health data use zero-retention endpoints only, as described above, and fail rather than fall back.
- There is exactly one route to a model. The gateway client is imported in a single file, so a new feature cannot accidentally reach a model without these policies applied.
- Research calls send no attendee data, only company and destination names.
- When a team member asks for a suggested report summary, the program's issue titles, including health-related ones, are sent to our AI provider over a zero-retention endpoint.
- Actions are proposed, not taken. Where the assistant can change data it does so through the same permission checks as a person, and material changes are surfaced for confirmation and labeled in the audit trail as AI-sourced.
Model providers are listed in the subprocessor register below. Note that web-search research is a plugin at the routing layer, and zero-retention guarantees do not extend to a search leg; we therefore do not send attendee data on that path at all.
Siri and Gemini on the phone
A customer can let its team use Siri on iPhone, and the Gemini app, with DMC Pilot. It is off until an owner turns it on for the organization and each person turns it on for their own phone, and turning either off ends it.
- Voice questions to Dispatch. When a person asks Siri to pass a question to Dispatch, Apple turns the speech into text, as it does for any app. We receive the text, answer it like any other Dispatch question, under the same model policies above, and keep the question and the answer in that person's own Dispatch conversation so the full answer can be read in the app. A spoken answer never contains prices, guest names, health or dietary details, phone numbers or email addresses.
- Names in the iPhone's search. While the feature is on, the app adds the names of the person's programs, companies and contacts (up to 150 of each) to that iPhone's own search, so they can be found from Spotlight and offered by Siri. Only names are added, never details. Apple keeps this index on the device for the system's use; on devices with Apple Intelligence, Apple's models may also process these names and the answers Siri speaks. The names are removed when the person signs out, when either switch is turned off or the phone is disconnected, and on their own after fourteen days if the app is not opened.
- Gemini. Gemini reaches DMC Pilot through AI Connections, described under what is not on the subprocessor list. It can read and never act, and Google keeps the conversation in the person's Gemini activity under Google's own terms.
Sharing and subprocessors
We do not sell personal data and we do not share it for advertising. We disclose it to the service providers below, each engaged under terms requiring confidentiality and security, and only as needed to run the platform. We also disclose data where legally compelled, and would notify the affected customer unless prohibited from doing so.
The full register is in the Subprocessors section below, which is also where changes are announced.
International transfers
The platform's database and application run in the United States, in the us-east-2 region, and file storage selects its region automatically. Our subprocessors are predominantly US-based. Personal data of people in the EEA, the UK and Switzerland therefore leaves those territories.
Where that happens, the transfer requires an Article 46 safeguard. Our position, stated plainly. The technical measures that support such a transfer (encryption in transit and at rest, additional field-level encryption for sensitive data, access control and logging) are in place and described in §11. We have also completed a transfer impact assessment covering every subprocessor against US surveillance law, which concludes that transfers may proceed with those measures and that no residual risk is high.
What is not yet done is execution: the Standard Contractual Clauses have not been countersigned with customers, and we will not describe them as in place before they are. Two findings from that assessment are worth knowing regardless. Health data is materially protected against compelled disclosure, because the database and file storage providers do not hold the key that decrypts it. Ordinary attendee details, names, contacts, travel, are not: they are readable by a compelled infrastructure provider, and no measure available to us changes that without breaking the product. A customer for whom EU data residency is a requirement should raise it with us before contracting, because today we cannot offer it.
How long we keep data
The platform enforces retention rather than leaving it to good intentions. Health data is cleared on a fixed schedule that no setting can lengthen. Each other class of data below has a default period, and a customer can adjust it within bounds that the software enforces on both write and read, a value outside the range is clamped, not honored; those classes are deleted once the customer switches enforcement on, and reported on until then. Expiry is evaluated daily.
| Data | Default | Customer may set | Why |
|---|---|---|---|
| Health, dietary and accessibility details | 30 days after the program ends | Fixed: cannot be lengthened | Special-category data with the shortest useful life of anything here: it exists to brief a caterer, and stops being needed once the event is over. It is cleared on this schedule whether or not the other classes below are switched on. |
| Attendee records | 1 year after the program ends | 30 days to 3 years | Names, contacts and travel details, kept long enough to handle post-event queries and repeat bookings. |
| Staff check-in location and device data | 90 days | 7 days to 1 year | Location, IP and device recorded at clock-in. Kept for the payroll and dispute window, not as a movement history. |
| Notifications | 90 days | 7 days to 1 year | In-product alerts, which have no value once read and acted on. |
| Assistant conversations and memories | 180 days | 30 days to 2 years | Chat history and learned preferences that make the assistant useful across a season. |
| Soft-deleted records | 30 days | 7 days to 1 year | The undo window after something is deleted in the product, after which it is purged for real. |
| Unsent chat drafts | Deleted 30 days after the last edit, or when sent | Fixed | |
| Activity and audit logs | 1 year | 90 days to 7 years | Who did what, and when. The floor is higher than the others on purpose, an audit trail a customer can shorten at will is not an audit trail. |
Two honest caveats. First, deletion for the six configurable classes is opt-in per organization: until a customer turns it on, those classes run in reporting mode. The fixed health-data ceiling is enforced regardless of that switch. Second, data erased from the live system can persist in a backup until that copy expires; backups are used only to restore the service, never to answer a query about a person.
Separately, we retain our own business records, contracts, invoices and tax documentation, for as long as the law requires, typically seven years.
Security
Our security measures and privacy practices are set out in detail on our Security and trust page. In summary: tenancy isolated in the database rather than the interface; every server action enforcing its own authorization check; encryption in transit and at rest, with additional field-level encryption and key rotation for sensitive personal data; invitation-only accounts with granular permissions, optional two-factor authentication and single sign-on on the Enterprise plan; an audit trail that survives account deletion; automated daily database backups; and error monitoring that scrubs personal data before it leaves the application.
Your rights
Where the GDPR or UK GDPR applies you have the right to access your data, to have it corrected, to have it erased, to restrict or object to processing, to receive it in a portable form, and to withdraw consent where consent is the basis. You also have the right not to be subject to a solely automated decision with legal or similarly significant effects, see §16.
Account holders can exercise access and erasure directly in the product, under Settings → Data & Privacy, without asking us. The export includes account data, notifications, assistant conversations and memories, and activity history. For staff whose employer uses time tracking it also includes their own location, address, IP and device records.
Two limits worth stating in advance rather than on refusal. Erasing an account does not erase the audit trail of what that account did: the record is retained with the actor replaced by an irreversible pseudonym, which Article 17(3) permits and which we regard as necessary, an audit log that can be emptied by deleting an account is not an audit log. And the sole remaining super administrator of an organization cannot erase themselves, because access is invitation-only and doing so would strand the organization's data with nobody able to reach it.
California privacy rights
Privacy operations are owned by Julien de Bats, founder/CEO. Our written request procedure explains how we verify authorized agents and handle requests. This operational role does not constitute a statutory DPO or EU/UK representative appointment.
This section is our notice at collection under the CCPA as amended by the CPRA, and applies to California residents.
We do not sell personal information, and we do not share it for cross-context behavioral advertising. We have never done either. There is consequently no “Do Not Sell or Share My Personal Information” mechanism to offer, and any site that presents one while doing what we do is describing a different business.
The categories we collect, and why:
| Category | Collected | Purpose |
|---|---|---|
| Identifiers | Name, work email, account identifier, IP address | Providing and securing the service; responding to inquiries |
| Commercial information | Subscription, plan and billing records | Billing and statutory records |
| Internet activity | Aggregate page views; application error and audit records | Operating, debugging and securing the service |
| Geolocation | Position at staff check-in, where a customer uses time tracking | Verifying attendance and hours worked |
| Professional information | Employer, job role, permissions | Access control within a customer's organization |
| Sensitive personal information | Health data in the form of dietary requirements and allergies; precise geolocation at check-in | Catering and duty of care for an event; verifying attendance. Used only to deliver the service requested, never to infer characteristics, and never for profiling |
You have the right to know what we collect and to receive a copy, to delete it, to correct it, to limit our use of sensitive personal information, and not to be discriminated against for exercising any of these. We do not use sensitive personal information for any purpose beyond providing the service, which is the limit the statute allows you to request in any event. An authorized agent may act for you on proof of authority. Where the data belongs to a customer's organization we will refer the request to them as the business, and support them in answering it.
Making a request
Email privacy@dmcpilot.com. We acknowledge within five working days and respond substantively within one month, which we may extend by two further months for a complex request, telling you why, within the first month, if we do. Requests are free unless manifestly unfounded or excessive.
We will verify your identity in proportion to the sensitivity of what is requested, using the account you are asking about wherever possible rather than asking you for new identity documents. Every request we receive is logged with its outcome and timing, so that our handling of it is itself auditable.
If you are an event attendee rather than a user of the software: the organization that invited you is the controller of your data and is the correct recipient of your request. If you contact us we will tell you so, and where we can identify the customer we will pass the request to them promptly.
Breach notification
Where we act as processor and become aware of a personal data breach we notify the affected customer without undue delay, with the information they need to meet their own 72-hour obligation to a supervisory authority. Where we act as controller we notify the relevant authority within 72 hours where the breach is likely to result in a risk to people, and notify affected people directly where the risk is high.
Automated decision-making
The platform scores vendor reliability, flags margin risk, clusters transfers and suggests actions. None of these produces a decision about a person with legal or similarly significant effect, and none operates without a person able to see and override the output. Vendor scores are explainable by design: the factors behind a score are shown alongside it, because a supplier told their rating dropped is entitled to know which delivery caused it.
Children
The platform is business software and is not directed to children. We do not knowingly collect data from anyone under 16. A customer running an event with minors in attendance is the controller of that data and carries the corresponding obligations, including parental consent where required; if you believe a child's data has reached us in error, contact us and we will work with the customer to remove it.
Changes
We will update this policy as the platform changes. The effective date at the top always reflects the current version. Where a change materially affects how we handle personal data we will notify customers by email or in the product before it takes effect, and for changes to the subprocessor list the notice period in the Data Processing Addendum applies.
Contact and complaints
Privacy inquiries and requests: privacy@dmcpilot.com. Security reports: security@dmcpilot.com, and see our disclosure policy.
Controller: Digital Envision LLC, 16192 Coastal Highway, Lewes, DE 19958, United States of America. No Data Protection Officer has been appointed at the time of writing.
EEA representative under Article 27: [TO BE COMPLETED]. UK representative: [TO BE COMPLETED]. We are established in the United States and have no establishment in the Union, so these appointments are required of us and are outstanding. One consequence worth stating for anyone considering a complaint: because we have no establishment in the Union, the one-stop-shop under Article 56 does not apply to us. There is no single lead authority, and the authority in your own country may act.
You have the right to complain to a supervisory authority. In the EEA that is the authority where you live, work or where the issue arose; in the UK it is the Information Commissioner's Office. We would rather you raised it with us first, but that is your choice and not a precondition.
Subprocessors
The 18 third parties that process personal data on our behalf, what each one actually receives, and where it operates. This register is compiled from the source code rather than from memory, because a register that has drifted from the software is worse than none. It is the document a customer relies on under their Data Processing Addendum.
How changes are notified
Under §5 of the Data Processing Addendum we give at least 30 days' notice before adding or replacing a subprocessor. Notice goes to each customer's administrative contact by email, and this section is updated at the same time. A customer may object on reasonable data protection grounds within that period; if we cannot accommodate the objection, they may terminate the affected subscription without penalty.
We may replace a subprocessor on shorter notice where it is necessary to preserve security or continuity (a provider suffering a breach, for instance) and will explain why as soon as practicable.
To be notified without being a customer, email privacy@dmcpilot.com.
Reading the health-data column
One class of data in the platform is special category data under Article 9 of the GDPR: dietary requirements and allergies. Because that carries stricter obligations, the tables below say for every provider whether it can receive it.
- Yes, the provider holds or transports this data as part of its normal function. 4 of 18 providers.
- Only if present, the provider does not handle it by design, but could receive it incidentally: inside an error report, a log line, or a specific request that needed it.
- No, the data cannot reach this provider by any path.
Health data reaches an AI provider only when someone asks a question or requests a draft that requires it, over a zero-data-retention endpoint, and each such access is written to the activity log. It is not included in the routine context supplied to the assistant.
The register
Infrastructure
| Provider | Purpose | Personal data received | Location | Health data |
|---|---|---|---|---|
| Supabase | Primary database, authentication and object storage | Everything the product stores: accounts, program and attendee records including dietary and allergy fields, waivers, chat, timesheets including location and IP | United States (us-east-2) | Yes |
| Vercel | Application hosting, serverless execution and scheduled jobs | All request data in transit; operational logs may contain IP addresses | United States, with a global edge network | Only if present |
| Cloudflare R2 | File and document storage and photo albums | Uploaded documents and images | Automatic region selection | Yes |
| Cloudflare Email Routing and Workers | Receiving email forwarded to a program's inbound address and handing it to the application | Every forwarded email in full, with its attachments: senders, recipients, and whatever the message carries, including rooming lists and dietary changes | Global edge network | Yes |
| Upstash | Distributed rate limiting | IP addresses and user identifiers, held transiently as rate-limit keys | United States | No |
| Sentry | Application error monitoring and session replay | Stack traces, user identifier only, scrubbed request context | United States | Only if present |
Communications and payments
| Provider | Purpose | Personal data received | Location | Health data |
|---|---|---|---|---|
| Resend | Transactional email, invitations, proposals, digests, alerts | Recipient name and email address, message contents | United States | No |
| Expo (EAS Push) | Mobile push notification relay for the DMC Pilot iOS and Android app | Device push tokens and short notification previews: sender first name and up to 140 characters of the chat message as written. No attendee record field is ever sent | United States | Only if present |
| Apple Push Notification service and Google Firebase Cloud Messaging | Delivering the push notifications Expo relays to iPhones and Android phones | The same device tokens and short previews Expo relays | United States | Only if present |
| Stripe | Subscription billing, add-ons and usage charges | Billing contact details and payment instrument, which Stripe holds and we never receive | United States | No |
| Cal.com | Demonstration booking on the public website only | Name, email address and any answers given when booking a call | United States | No |
Artificial intelligence
| Provider | Purpose | Personal data received | Location | Health data |
|---|---|---|---|---|
| OpenRouter | Model gateway, the single route by which any language model is called | The contents of the prompt for the feature in use | United States | Yes |
| Google (Gemini), via OpenRouter | Assistant answers, document and manifest analysis, safety guards | Program context and attendee names; dietary and allergy fields only when a question requires them | United States | Only if present |
| OpenAI, via OpenRouter | Fallback for assistant answers and guards | As above | United States | Only if present |
| Perplexity, via OpenRouter | Client and destination research requiring web search | Company and destination names only, no attendee data | United States | No |
| TypeSafe, via OpenRouter | Decisions with a confidence: the kind and urgency of inbound email, whether it needs a reply, which attachments matter, how import columns map, and the assistant's scope and grounding checks | An inbound email's sender, subject and newest message; attachment names; import column headers with a few sample values; the question and answer an assistant check reads | Through OpenRouter, United States | Only if present |
Operational data sources
| Provider | Purpose | Personal data received | Location | Health data |
|---|---|---|---|---|
| AviationStack / FlightAware | Flight status tracking | Flight numbers and dates only, no personal data | United States | No |
| Mapbox | Geocoding, maps and place search | Addresses and place queries | United States | No |
Why AI providers are listed individually
Every language-model call in the platform goes through a single gateway, OpenRouter. It would be tempting to list only the gateway and stop, but that would be misleading: a gateway routes, and the provider it selects has its own terms. So the upstream providers are named separately, because they are the ones actually running the inference.
Two settings govern this, and both are applied rather than assumed. Every request is sent with data collection denied, which excludes any provider that stores or trains on inputs. That matters because the gateway's default is to permit them. Requests that could carry health data additionally require zero-data-retention endpoints, which do not retain the request at all; if none is available the request fails rather than routing somewhere that would keep it. Independently, the account-level settings with the gateway exclude every training endpoint.
The decision model from TypeSafe is held to both settings on every call, not only on calls that could carry health data, and each call carries only the fields its question needs: the newest message of an email rather than the thread, a column's header and a few sample values rather than the sheet. It returns a choice and a confidence; it writes no text of its own.
One limitation worth naming: zero-retention guarantees do not extend to search plugins, and the research feature performs web search. We therefore send no attendee data on that path at all, only company and destination names.
Location and transfers
Every provider above operates in or from the United States. Personal data of people in the EEA, the UK and Switzerland therefore leaves those territories, which requires an Article 46 safeguard. The technical measures supporting such transfers are in place, and the transfer impact assessment covering every provider above against FISA 702, EO 12333 and the CLOUD Act is complete. What is outstanding is execution: the Standard Contractual Clauses are not yet countersigned with customers, as stated in §11 of the Addendum. EU data residency is not available today.
What is not on this list
Services that receive no personal data are excluded on purpose, so that the register stays the list of places personal data actually goes. Flight tracking and mapping are the two exceptions listed above anyway: flight tracking receives flight numbers and dates, and mapping receives addresses and place queries. Neither receives a name, but an address or an itinerary can point to a person, so both are named.
Systems a customer chooses to connect are also not listed, because the customer selects them and we do not engage them. An accounting system connected in Settings (Xero or QuickBooks Online) receives the customers, invoices, payments and credit notes that organization sends to it. An AI assistant that a user connects through AI Connections receives the records that user may read, on their consent, and never health data.
We use no advertising, marketing-automation or data-broker provider of any kind, on the website or in the product. The website's analytics are Vercel Web Analytics, which is cookieless, and Google Analytics, which sets cookies only with your consent, see the Cookie Notice. The product itself contains no analytics provider.
Cookies
This website sets two kinds of cookies, and only in two situations: Google Analytics cookies if you accept them in the banner, and Cal.com’s cookies on the booking page, where the calendar is embedded. Otherwise browsing the site sets none. This notice says precisely where each happens, and what the application itself stores to keep you signed in.
The website
Until you answer the cookie banner, browsing this site sets no cookies and does not follow you anywhere else. Your answer itself is remembered in your browser's local storage, so that we do not ask on every page; that is the only thing stored. The two exceptions are Google Analytics, if you accept, and the booking calendar.
Analytics are provided by Vercel Web Analytics, which is cookieless by design. It counts page views and a small number of interactions, such as which call to action was used. Visitors are counted using a hash derived from the request, which is discarded within 24 hours, and results are stored as aggregates rather than against a person or an IP address. There is no cross-site tracking, no advertising network, no marketing pixel, no session recording and no data broker, on this site or in the product.
What you type is never sent to analytics. When the contact form is submitted we record only whether it succeeded or failed. Your name, email, company and message go to us by email and nowhere else.
Google Analytics
We use Google Analytics to understand which pages are read and which lead to a demonstration. On your first visit a small banner asks whether you accept its cookies. Nothing is set unless you choose Accept.
- If you accept, Google Analytics sets the cookies below, and Google receives the pages you view, how you arrived, your browser and device type and an approximate location. Google does not log or store IP addresses for Google Analytics.
- If you decline, or have not answered, the Google Analytics script is not loaded. No cookie is set, no identifier is stored, and Google receives nothing from this site.
- Advertising features are switched off: nothing is shared for advertising, personalization or remarketing, and the same setting holds whatever you choose.
- Clicks we already count, such as which call to action was used or that a booking happened, are also sent to Google Analytics under the same choice. What you type never is.
| Cookie | Purpose | Lifetime |
|---|---|---|
_ga | Tells one visitor from another, so returning visits are counted once | 2 years |
_ga_WK9RGYLRGP | Keeps the current visit together as one session | 2 years |
Google Ireland Limited and Google LLC process this data under Google's terms, and it may be transferred to the United States under the safeguards Google provides. Reports are kept for the retention period set in our Google Analytics account, at most 14 months.
You can change your answer at any time. Declining after accepting also removes the Google Analytics cookies from this site.
The booking calendar
The demonstration booking calendar is provided by Cal.com and runs inside our page as an embedded frame. It loads with the page, and when it does, Cal.com sets its own cookies in your browser. That happens on the booking page only, and only on that page. It does not happen anywhere else on this site.
We had this behind a button for a while, so that nothing from Cal.com ran until you asked for it. It was better for privacy and worse for everyone trying to book a call: the calendar takes a few seconds to appear, so the page looked broken. We removed the button and are telling you here instead.
If you would rather not load it at all, do not open the booking page. Email privacy@dmcpilot.com or use the contact form, which sets nothing, and we will arrange a time by email. Your browser's third-party cookie blocking will also stop it, and the rest of the site is unaffected either way.
The calendar operates under Cal.com's own privacy policy as well as ours, and the name, email and answers you give when booking go to Cal.com and to us so that we can hold the meeting. To arrange a time without using it, email privacy@dmcpilot.com and we will arrange a time directly.
We record that a booking happened, for analytics. We never record who made it.
The application
The platform at app.dmcpilot.com is different: signing in requires remembering that you are signed in. These are strictly necessary cookies, exempt from consent requirements, and there are no others.
| Purpose | What it is | Lifetime |
|---|---|---|
| Authentication | Session and refresh tokens issued by our authentication provider, which keep you signed in across page loads and are required for every authorized request | Until you sign out or the session expires |
| Two-factor state | Records that a second factor has been satisfied for the current session, so you are not challenged on every page | The session |
| Support access | Set only when a member of our support team is accessing an organization with authorization. It is bound to the signed-in administrator, and every use is written to an audit log that deleting an account cannot remove | The support session |
| Interface preferences | Small values remembering things like whether the sidebar is collapsed | Until cleared |
The product contains no analytics cookie, no advertising cookie and no third-party tracker. Error monitoring runs without one, and its payloads are scrubbed of identity, credentials, cookies and sensitive fields before leaving the application.
Your control
You can change your Google Analytics answer with the button in the Google Analytics section, and block or delete cookies in your browser settings. Blocking them on the website costs you nothing: every page works the same without them. Blocking them for the application will prevent you from signing in, since the authentication cookies are what a signed-in session consists of.
Changes
If we ever introduce a cookie that is not strictly necessary, we will ask for your consent before setting it and update this notice first. Questions: privacy@dmcpilot.com.
Questions about this document: legal@dmcpilot.com. Privacy requests: privacy@dmcpilot.com. Security reports: security@dmcpilot.com.