Privacy Policy

This page explains what data Agenola collects, why, who we share it with and how long we keep it. There are two distinct relationships and they should not be confused: businesses that sign up to Agenola, and visitors who talk to that business's avatar.

Two different roles

For the BUSINESSES that sign up we are the data controller: we process your account and billing data for our own purposes.

For the VISITORS who talk to an avatar, the controller is the business that built it; we only process on that business's behalf. Informing the visitor and obtaining any required consent is that business's responsibility.

What we collect from businesses

Account: name, email address, a profile photo if you upload one, and an irreversible hash of your password. The password itself is never stored. If you sign in with Google you may have no password at all; the data we receive from Google is described separately below.

Security: the IP address, browser, country and last activity time of your open sessions, and an audit log showing who changed what in the panel, when, and from which address.

Usage: how many conversations were held each month, how many language-model tokens and how many seconds of speech synthesis and transcription were used. This is for billing and quotas.

Payment: subscription status and Stripe's customer and subscription IDs. CARD DETAILS NEVER REACH US; payment is taken on Stripe's own page.

Sign in with Google

When you sign in with “Continue with Google”, we receive only: your name, your email address, whether Google has verified that address, and the permanent identifier Google assigns to your account. These are the only permissions we request (openid, email, profile).

For sign-in we do not access Gmail, Drive, Contacts, Calendar or any other Google data, and we never see your Google password. We do not store the access token Google issues at sign-in, and we do not use or store your profile photo.

We use this information only to create your Agenola account, sign you in to it, and connect Google sign-in to an existing account with the same email address. Your name and email are kept in your account; the Google identifier and the email address at the time of linking are kept in the sign-in record attached to your account.

We do not sell or rent the data we receive from Google, we do not use it for advertising or to train AI models, and we do not share it with anyone other than the service providers needed to run Agenola.

You can remove our access at any time at https://myaccount.google.com/permissions; this stops Google sign-in but does not delete your account. You can ask us to delete your account at info@agenola.ai; when the account is closed its link to your Google account is removed and this data is no longer used.

Agenola's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements: https://developers.google.com/terms/api-services-user-data-policy

Google Calendar, Drive and Gmail connections

If an admin of your workspace connects Google Calendar, Google Drive or Gmail under Integrations, they give separate approval for that app on Google's permission screen. This is independent of sign-in: we do not access this data for any account that has not been connected, and each app asks only for its own permission.

The permissions we request are full access, and what we use them for: in Google Calendar, to read, create, change, delete and share your events and calendars, and to look up availability others have shared with you. In Google Drive, to search, read, create, edit, move, share and delete your files, and to edit the contents of documents, spreadsheets and presentations. In Gmail, to search, read, send, reply to, forward, label, archive and delete your emails, and to manage drafts, labels, filters, signature and auto-reply settings. Only the steps you add to your agents do these things.

We use this data only to run the Google steps you add to your agents. The workspace member who sets a step up decides which operation runs and on which file, calendar or email; the step then runs as configured for everyone who talks to the agent, including visitors who open the agent's public link. Steps that delete, share, or send email or invitations from your account do not run until the person who set them up confirms them on the step, and they run under an hourly limit; the target of a deleting or sharing step cannot be a value typed by a visitor.

Content a step reads (events, emails, file text, spreadsheet rows) can be written to the flow's variables. If the person who built the agent uses those variables in a message, the content is shown to the person talking to the agent; if they use them in an AI Assistant step, it is sent to our language model provider to produce the answer. This data is not used for advertising or to train AI models.

The result of each step (which step, when, whether it succeeded, and a shortened form of the values it returned) is kept for 7 days to prevent it from running twice, and is then deleted. Values you have written to the flow's variables can remain in the conversation record.

The access and refresh tokens Google issues are stored encrypted and used only for this purpose. When you remove the connection in the panel the tokens are no longer used, and if no other Google Calendar, Drive or Gmail connection of the same Google account remains, the permission is also revoked on Google's side. You can also remove the permission yourself at https://myaccount.google.com/permissions.

Google Analytics connection

If an admin of your workspace connects Google Analytics under Integrations, they give separate approval on Google's permission screen. This connection asks only for its own permissions (analytics.readonly and analytics.edit) and is independent of sign-in and of the Google Calendar, Drive and Gmail connections.

What we use them for: with analytics.readonly, to list the Google Analytics accounts, properties and web data streams you can access so you can choose one for an agent, and to run the reports you add to an agent, for the metrics and dimensions you select. With analytics.edit, only on the web data stream you choose: to accept Google's user data collection acknowledgement for that property, to create a Measurement Protocol secret named “Agenola” so your agents can send events to that stream, and to create or look up key events when you add that step to an agent. We do not manage users, accounts or any other property settings.

Report results that a step reads can be written to the flow's variables and are then handled like other step results: shown in a message, or sent to our language model provider in an AI Assistant step. This data is not sold, not used for advertising or to train AI models, and not shared with anyone other than the service providers needed to run Agenola.

The access and refresh tokens Google issues and the Measurement Protocol secrets we create are stored encrypted. When you remove the connection in the panel, the secrets we created are deleted from your data streams, the tokens are no longer used, and if no other Google Analytics or Google Ads connection of the same Google account remains, the permission is also revoked on Google's side. You can also remove the permission yourself at https://myaccount.google.com/permissions.

Google Ads connection

If an admin of your workspace connects Google Ads under Integrations, they give separate approval on Google's permission screen. This connection asks only for its own permissions (adwords and datamanager) and is independent of sign-in and of the other Google connections.

What we use them for, only through the Measurement settings and the Google Ads steps you add to your agents: with adwords, to list the Google Ads accounts you can access and the conversion actions and campaigns in the account you choose, to read the reports you add (the metrics you select), and to enable or pause a campaign when you add that step. We do not create campaigns or change ads, budgets, bids, billing or account users. With datamanager, to send conversions from your agents (for example contact details left, an appointment booked, a step you marked, a purchase made on a WooCommerce store) to the conversion actions you selected, and to create, update and delete Customer Match lists and add people to or remove them from those lists when you add those steps. A step that pauses a campaign or deletes a list does not run until the person who set it up confirms it on the step, and runs under an hourly limit.

A conversion contains its time, the conversion action, the value and currency if you set them, and the identifiers Google uses to match it to an ad interaction: the ad click identifier recorded when the visitor arrived from your ad, and the visitor's email address or phone number if they left one, sent only in irreversibly hashed (SHA-256) form. A person added to a customer list is likewise sent only as a hashed email address or phone number, and only after the person who set up the step accepts Google's Customer Match policy on it. Conversions and list members are sent only to your own Google Ads account, on your instruction; you are responsible for giving your visitors the notice and obtaining the consent their jurisdiction requires.

The data we read from Google Ads (account, conversion action, campaign and list names and identifiers, and the report results you request) is used only to show these choices in the panel and to run your steps; a step's results can be written to the flow's variables and are then handled like other step results. It is not sold, not used for advertising or to train AI models, and not shared with anyone other than the service providers needed to run Agenola.

The access and refresh tokens Google issues are stored encrypted and used only for this purpose. When you remove the connection in the panel the tokens are no longer used, and if no other Google Analytics or Google Ads connection of the same Google account remains, the permission is also revoked on Google's side. You can also remove the permission yourself at https://myaccount.google.com/permissions.

Meta Pixel connection

If an admin of your workspace connects Meta Pixel from the Integrations section, they choose their business and the pixels Agenola may access in Meta's window and give their approval. This connection asks only for the ads_read and business_management permissions. Meta creates a system user for Agenola in the approved business; the connection works with that user's access token and isn't tied to the Facebook account of the person who approved it.

What we use it for (only through Measurement settings and the Meta steps you add to your agents): with business_management we list the pixels owned by or shared with your business so you can choose one for an agent; with ads_read we send events to the pixel you chose through the Conversions API (for example conversation started, contact details left, appointment booked, a step you marked reached, a purchase made on a WooCommerce store). We don't read or change campaigns, ads, budgets, audiences, Pages or business users.

An event carries its name and time, the value and currency if you set them, and the information Meta uses to match it with an ad interaction: a pseudonymous visitor identifier derived from the session, the visitor's browser details (user agent) and IP address, the address of the page where the chat was opened (without the query part), the ad click identifier (fbclid) if the visitor came from a Meta ad and, if the visitor left them, an email address or phone number; these two only in irreversibly hashed form (SHA-256). Events are sent only on your instruction and only to your pixel; giving your visitors the notice and obtaining the consent their location requires is your responsibility.

The data we read from Meta (the business's name and ID, the pixels' names and IDs) is used only to show these options in the dashboard and to run your steps. It isn't sold, isn't used for advertising or to train AI models, and isn't shared with anyone other than the service providers needed to run Agenola.

The access token Meta issues is stored encrypted and used only for this purpose. When you remove the connection in the dashboard the token is no longer used; to remove Agenola on Meta's side as well, use Meta Business Settings → Integrations → Connected apps (https://business.facebook.com/latest/settings/connected_apps). Once removed there, the system user and its token stop working at Meta too.

TikTok connection

If an admin of your workspace connects TikTok from the Integrations section, they choose on TikTok's page which ad accounts Agenola may access, approve the permissions and verify their identity with a code sent to the ad account's email. This connection asks for only three permissions: reading ad account information (Read Ad Account Information), reading pixels (Read Pixels) and sending conversion events (Report Conversion Event).

What we use it for (only through Measurement settings and the TikTok steps you add to your agents): we list the names of the ad accounts you allowed and the pixels in those accounts so you can choose one for an agent; we send events to the pixel you chose through the Events API (for example conversation started, contact details left, appointment booked, a step you marked reached, a purchase made on a WooCommerce store). We don't read or change campaigns, ads, budgets, audiences or account settings.

An event carries its name and time, the value and currency if you set them, and the information TikTok uses to match it with an ad interaction: a pseudonymous visitor identifier derived from the session, the visitor's browser details (user agent) and IP address, the address of the page where the chat was opened (without the query part), the ad click identifier (ttclid) if the visitor came from a TikTok ad and, if the visitor left them, an email address or phone number; these two only in irreversibly hashed form (SHA-256). Events are sent only on your instruction and only to your pixel; giving your visitors the notice and obtaining the consent their location requires is your responsibility.

The data we read from TikTok (the names and IDs of ad accounts and pixels) is used only to show these options in the dashboard and to run your steps. It isn't sold, isn't used for advertising or to train AI models, and isn't shared with anyone other than the service providers needed to run Agenola.

The access token TikTok issues is stored encrypted and used only for this purpose. When you remove the connection in the dashboard, the token is also revoked at TikTok. You can also remove access in TikTok's authorization settings (https://ads.tiktok.com/ac/page/authorizations).

Shopify connection

If an admin of your workspace connects a Shopify store from the Integrations section, they grant the Agenola app access on Shopify's approval screen. This connection asks for four kinds of permissions: storefront permissions (reading products, stock and published store pages, and building the visitor's cart), store management permissions (products, variants, collections, stock, publishing to sales channels, discount codes and store pages), order permissions (reading orders, writing to the order's note, and cancelling, holding and refunding orders) and customer permissions (reading, creating, updating and deleting customer records).

What we store: the store's .myshopify.com address, its storefront domain, its name, the permissions Shopify granted, a Storefront API key and the admin access token. The admin access token is stored encrypted.

What we use it for: when a visitor asks a question, we read product names, descriptions, prices, availability and published store pages from Shopify at that moment; the catalogue is not copied into Agenola. If the visitor adds a product to the cart in the chat, the cart is created in Shopify and payment happens on Shopify's own checkout page. With the admin access token we read the store's name and domain, create the Storefront API key and save the address of the agent page in the app's own settings; in the store management steps you add to your agents, we change products, variants, collections, stock, discount codes and pages only as you configured them in that step. The ready-made agent set up when the store is connected does not expose these steps to visitors.

Orders: when a visitor asks the agent about their own order, the agent asks for the order number and the email address or phone number used on the order; we read that order from Shopify at that moment and check whether this information matches the email or phone on the order. If it matches, we tell the visitor the order's status, total, products, delivery city, shipment tracking and the address of Shopify's order status page; the address, email and phone on the order are not shown to the visitor, and wrong attempts are limited. A customer signed in to the store is not asked for an order number or email address; only orders on their own account are read (see “What is collected from visitors”). If the visitor leaves a cancellation, return, exchange or address request, it is added to the order's note; the order itself does not change. If you turn it on in the dashboard, once the order is verified and the visitor explicitly confirms, the visitor can use the agent to cancel an order that hasn't shipped (the payment is refunded to their payment method) or to open a return request in Shopify for shipped products; you approve or decline the request. In the order steps you add to your agents, we read orders (number, status, total, the customer's name and email, payment method, products) and, as you configured them in that step, add a note to the order, or cancel, hold or refund it. In the customer steps you add to your agents, we read customer records (name, email, phone, addresses, order count, total spent) and, as you configured them in that step, create, update or delete them. No copy of the orders or customer records is kept in Agenola; the number and amount of a sale that came through the agent are kept for sales attribution. What the visitor writes in the conversation and the replies they get are kept in the conversation record.

When the app is uninstalled from Shopify, when you remove the connection in the panel, or when Shopify asks for the store's data to be erased, the connection is closed, the agent is removed from the storefront and the access tokens are no longer used. When Shopify asks for the store's data to be erased (48 hours after the app is uninstalled), we also erase the content of all the conversations of the store's agent; if the store has been connected again in the meantime, nothing is erased. When Shopify requests a customer's data, we find the agent conversations in which that customer's email address, phone number or order appears and notify the store owner by email. When Shopify asks for the customer's data to be erased, we erase the content of those conversations; information that doesn't identify the person, such as dates and counts, remains.

Slack connection

If an admin of your workspace connects Slack under Integrations, they approve Agenola's Slack app on Slack's permission screen.

What we receive: the Slack workspace's ID and name, a bot token for the app, and a user token for the person who connected. The user token is used only for status updates, which Slack doesn't allow with a bot token. To fill the channel pickers we read the names of the channels the app can see.

What we use it for: to post the notifications you route to Slack, and to run the Slack steps you add to your agents (sending, updating or deleting messages; managing channels and user groups; uploading files; adding reactions; looking people up). We read messages, files, reactions and people's details only when a step you added asks for them; we don't read your channels in the background and we don't copy your Slack workspace.

Content a step reads can be written to the flow's variables and is then handled like other step results: shown in a message, or sent to our language model provider in an AI Assistant step to produce the answer. It is not used for advertising or to train AI models.

How long we keep it: tokens are stored encrypted until the connection is removed. The result of each step is kept for 7 days to prevent it from running twice, then deleted. Values written to the flow's variables can remain in the conversation record until you delete it or ask us to.

Removing it: when you remove the connection in the panel, the app is uninstalled from your Slack workspace and its tokens stop working. You can also remove the app from Slack yourself. To have your data deleted, write to info@agenola.ai.

HubSpot connection

If an admin of your workspace connects HubSpot under Integrations, they install Agenola's HubSpot app in their account and approve it on HubSpot's permission screen.

What we receive: the HubSpot account's ID, domain and data center, the email address of the person who connected, and access and refresh tokens. The permissions we request: reading and writing contacts, companies and deals (crm.objects.contacts, crm.objects.companies, crm.objects.deals); reading record owners (crm.objects.owners.read); reading the property definitions of these records (crm.schemas.contacts.read, crm.schemas.companies.read, crm.schemas.deals.read). We don't request permissions for sensitive data.

What we use it for: to run the HubSpot steps you add to your agents (finding, creating and updating contacts; creating companies; reading and updating deals; adding, updating or deleting notes and tasks; associating records) and to fill the step's pickers (record owners, pipelines). We read records only when a step you added asks for them; we don't read your HubSpot account in the background and we don't copy it. A visitor's details reach HubSpot through the step the business sets up; the business is responsible for that data in HubSpot.

Removing it: when you remove the connection in the panel, Agenola is uninstalled from your HubSpot account and its tokens stop working; if the same HubSpot account is also connected to another Agenola workspace, only this connection's access is revoked. You can also remove the app yourself under Integrations → Connected apps in HubSpot's settings. To have your data deleted, write to info@agenola.ai.

Pipedrive connection

If an admin of your workspace connects Pipedrive under Integrations, they install Agenola's Pipedrive app for their own Pipedrive user and approve it on Pipedrive's permission screen.

What we receive: the Pipedrive company's ID, name and address; the ID, email address and default currency of the person who connected; and access and refresh tokens. The permissions we request: reading and writing persons and organizations (contacts:full), deals (deals:full), leads (leads:full) and activities (activities:full); reading users (users:read); searching (search:read); and the connecting person's basic details (base). We don't request permissions for email, products or admin settings.

What we use it for: to run the Pipedrive steps you add to your agents (finding, creating and updating persons; creating organizations and leads; reading and updating deals and leads; adding notes; creating, updating or deleting activities) and to fill the step's pickers (users, stages, activity types, lead labels). Steps work with the connecting person's access and see only the records that person can see. We read records only when a step you added asks for them; we don't read your Pipedrive account in the background and we don't copy it. A visitor's details reach Pipedrive through the step the business sets up; the business is responsible for that data in Pipedrive.

Removing it: when you remove the connection in the panel, Agenola is uninstalled from Pipedrive for the person who connected and its tokens stop working; if another Agenola workspace uses the same person's connection, only this connection's access is revoked. You can also remove the app yourself in Pipedrive's settings, among your installed apps; the connection then shows in the panel as needing to be connected again. To have your data deleted, write to info@agenola.ai.

Zoho CRM connection

If an admin of your workspace connects Zoho CRM under Integrations, they approve Agenola's Zoho app for their own Zoho user on Zoho's permission screen; if there is more than one Zoho CRM organization, they choose the one to connect.

What we receive: the Zoho CRM organization's ID, name and the part of its web address that identifies it; the addresses of the account's data center; the Zoho CRM ID and email address of the person who connected; and access and refresh tokens. The permissions we ask for: create, read and update leads, contacts and accounts (ZohoCRM.modules.leads, contacts, accounts); read and update deals (ZohoCRM.modules.deals); add and read notes (ZohoCRM.modules.notes); manage tasks (ZohoCRM.modules.tasks.ALL); read fields, layouts and pipelines (ZohoCRM.settings.fields, layouts, pipeline); read users and organization details (ZohoCRM.users.READ, ZohoCRM.org.READ); query and search (ZohoCRM.coql.READ, ZohoSearch.securesearch.READ). We don't ask for permission to delete leads, contacts, accounts or deals.

What we use it for: to run the Zoho CRM steps you add to your agents (finding, creating and updating leads and contacts; creating accounts; converting leads; reading and updating deals; adding notes; creating, updating or deleting tasks) and to fill the step's lists (users, stages, source, status and priority options). Steps work with the connecting person's access and see only the records that person can see. We read records only when a step you added asks for them; we don't read your Zoho CRM account in the background or copy it. A visitor's details reach Zoho CRM through a step the business sets up; the business is responsible for that data in Zoho CRM.

Removing it: when you remove the connection in the panel, this connection's refresh token is revoked at Zoho and its tokens stop working; the same person's connection in another Agenola workspace isn't affected. You can also remove Agenola's access yourself in your Zoho account's settings; the connection then shows in the panel as one that needs to be connected again. To have your data deleted, write to info@agenola.ai.

Asana connection

If an admin of your workspace connects Asana under Integrations, they grant Agenola access on behalf of their own Asana account on Asana's permission screen.

What we receive: the Asana ID and name of the person who connected; the IDs and names of the Asana workspaces they belong to; and access and refresh tokens. The permissions we request: reading workspaces, teams, users and tags (workspaces:read, teams:read, users:read, tags:read); reading, writing and deleting projects and tasks (projects:read/write/delete, tasks:read/write/delete); and reading and writing comments (stories:read/write). We don't request full access to the Asana account, or permissions for attachments, portfolios, goals or admin settings.

What we use it for: to run the Asana steps you add to your agents (creating, reading, listing, searching, updating and deleting tasks; adding subtasks, comments and tags; adding a task to a project or removing it from one; creating, reading, updating and deleting projects; reading user details) and to fill the step's pickers (workspaces, teams, projects, tasks, people, tags). Steps work with the connecting person's access and see only the projects and tasks that person can see. We read records only when a step you added asks for them; we don't read your Asana account in the background and we don't copy it. A visitor's details reach Asana through the step the business sets up; the business is responsible for that data in Asana.

Removing it: when you remove the connection in the panel, Agenola's refresh token in Asana is revoked and its access tokens stop working. You can also remove Agenola's access yourself under Apps in your Asana profile settings; the connection then shows in the panel as needing to be connected again. To have your data deleted, write to info@agenola.ai.

Brevo connection

If an admin of your workspace connects Brevo under Integrations, they approve Agenola's Brevo app on Brevo's permission screen.

What we receive: the Brevo account's ID, company name and email address; and access and refresh tokens. The permissions we request: reading account details (account:read); reading and writing contacts, lists and contact fields (contacts:read, contacts:write); reading and managing email campaigns (campaigns.email:read, campaigns.email:write); reading email templates (transactional.email:read); adding notes to contacts (crm:write). We don't request permissions for SMS, WhatsApp, sending transactional email, webhooks or account settings.

What we use it for: to run the Brevo steps you add to your agents (adding, updating and reading contacts; reading the subscription status; sending the confirmation email; adding a contact to a list or removing them from one; unsubscribing; adding notes; reading and replicating campaigns, sending test emails and campaigns, or deleting campaigns) and to fill the step's pick lists (lists, campaigns, confirmation email templates). We read records only when a step you added asks for them; we don't read or copy your Brevo account in the background. Visitors' details go to Brevo through the step the business sets up; the business is responsible for that data in Brevo.

Removing it: when you remove the connection in the panel, Agenola's refresh token in Brevo is revoked and its access tokens stop working. If Agenola's access is removed on Brevo's side, the connection shows in the panel as one that needs reconnecting. To have your data deleted, write to info@agenola.ai.

Omnisend connection

If an admin of your workspace connects Omnisend under Integrations, they give Agenola access to the Omnisend account on Omnisend's permission screen.

What we receive: the Omnisend account's (brand's) ID, name and website address; and access and refresh tokens. The permissions we request: reading account details (brands.read); reading and writing contacts (contacts.read, contacts.write); sending events (events.write); reading and managing campaigns (campaigns.read, campaigns.write). We don't request permissions for products, segments, automations, templates, forms or reports.

What we use it for: to run the Omnisend steps you add to your agents (adding, updating and reading contacts; reading the subscription status; subscribing and unsubscribing; adding and removing tags; sending events; reading, replicating, sending and deleting campaigns) and to fill the step's campaign pick lists. When a visitor opens a support request and leaves their email address, the request's subject, the agent's name, its urgency and the request number are recorded as an event on that email's contact in Omnisend; if the contact isn't in Omnisend, they're added without being subscribed. New contacts Agenola adds get the “source: agenola” tag; when a step subscribes a contact, Omnisend records that the consent came from Agenola. We read records only when a step you added asks for them; we don't read or copy your Omnisend account in the background. Visitors' details go to Omnisend through the step the business sets up or through the support request event of the connection the business makes; the business is responsible for that data in Omnisend.

Removing it: when you remove the connection in the panel, Agenola's access and refresh tokens in Omnisend are revoked. If Agenola's access is removed on Omnisend's side, the connection shows in the panel as one that needs reconnecting. To have your data deleted, write to info@agenola.ai.

Building agents with AI

When you build or edit an agent by describing it to the AI in the panel (“New Agent” → “Create with AI”, or “Ask AI” in the editor), the following is sent to our language model provider to build the agent: the requests you write and your answers to the AI's questions; the content of the agent you are editing; the sources you add (files and images you upload, the text of the knowledge base entries you select, the text of the web page whose address you give); and some details of your workspace (the names of connected integrations, tools, other agents and knowledge base entries). For knowledge base entries you marked as internal to your team, only the title is sent.

We keep these conversations together with your account and workspace: your requests, your answers, the AI's replies, the agent that was built, the files you attached and the technical usage details of each step (the model used, the amount of text processed, the cost). Files are kept in non-public storage in data centres in the European Union. Conversations that belong to an agent can also be seen by members of your workspace who can edit that agent: they can read the conversation and see the names of attached files, but cannot open the files or continue the conversation. Otherwise only you and authorised Agenola staff can access the conversations.

We use these records to provide the feature, monitor its cost and improve it; this includes understanding what kinds of agents people generally describe to the AI. This data is not sold and not used for advertising or to train AI models.

We recommend that you don't attach files or text containing other people's personal data; if you do, that data is handled in the same way.

What is collected from visitors

Answers to the questions the agent asks, the text transcript of the conversation, the IP address and the country derived from it, and where the visit came from (utm tags, ad click identifier, referring domain). If the agent is embedded in a storefront, the ad click identifier (gclid, gbraid, wbraid, fbclid or ttclid) is taken from the address of the store page the visitor opened.

If the agent includes a file upload step, the uploaded files (kept for ninety days) and the details read from them; if it includes a test step, the test score and its rationale.

Sales attribution (on WooCommerce and Shopify stores): if a visitor places an order in the same store within 7 days of talking to the agent, the store's Agenola plugin reports the order to us once it is paid: the order id and number, its time, the product amount after discounts (excluding shipping and tax), the order total, the currency, the billing email address and phone number, the IP address, browser details (user agent) and the values of the cookies described below. Of these we keep only the order id and number, the amounts, the currency, the times and the conversation the order is linked to. The email address and phone number are not stored; they are passed on only in irreversibly hashed form (SHA-256) to the business's own measurement platforms. An order that does not match an agent conversation is not stored. On Shopify the match comes from the cart the agent built: when the visitor goes to checkout from the chat, a signed reference to the conversation is written to the cart as a property that is not shown on the checkout page; when an order placed with this cart within 7 days is paid, Shopify notifies us. Here too we keep only the order id and number, the amounts, the currency, the times and the conversation the order is linked to. The order's email address, phone number, IP address and browser details are read only if Shopify reports that marketing is allowed for this visitor and that they haven't opted out of the sale or sharing of their data (decided by the store's privacy settings, the visitor's region and the permission they gave); without that permission the order is only counted in the dashboard.

Signed-in store customers (on WooCommerce and Shopify stores): if the visitor is signed in to the store where the agent is embedded, the store's Agenola plugin (on Shopify, Agenola's theme extension) passes us, when the agent opens, the customer's ID in that store, their first name and their account email address, signed by the store and valid for 15 minutes. It is used to answer questions about the customer's own orders without asking for an order number or email address (the order details are read from the store at that moment), to show the business who it is talking to in the conversation record and to pre-fill the contact details of a support request. The ID, first name and email address are kept with the conversation record. Nothing is passed for visitors who are not signed in.

VOICE RECORDINGS ARE NOT KEPT. The visitor's voice is sent to a transcription service to be turned into text and is not stored; what is kept is the transcript. The audio generated for the avatar's speech is cached on our server so the same sentence is not synthesised twice — that is our voice, not the visitor's.

Cookies and measurement

Session cookie: required for you to sign in; it is signed.

Language cookie: remembers the language you chose.

Google Analytics and Microsoft Clarity: measure how the site is used. They run ONLY IF YOU ALLOW THEM: on your first visit you can accept or reject them in the banner at the bottom of the page (“Performance cookies” in the cookie settings). You can withdraw your permission at any time from the “Cookie settings” link at the bottom of the site (in the dashboard, from the user menu). CLARITY RECORDS SESSIONS — your clicks and mouse movements on the page can be replayed. These measurement tools are NOT loaded on the avatar page embedded in a storefront or on businesses' agent links.

Cookie preference cookie (agenola_consent): remembers your choice for about six months; it is necessary. To be able to show your decision, we keep a record of each one: your choice, its date, the version and language of the text you saw, the page where you decided, a shortened form of your IP address (last part removed), your browser details and, if you were signed in, your account.

Meta Pixel: lets us count which of our ads on Facebook and Instagram bring people to Agenola, so we can run them well. It loads unless you reject “Targeting cookies” in the cookie settings: on your first visit, until you decide, it sends Meta the pages you view and when you create an account, start your free trial, connect your first store or start a paid subscription (a subscription also carries the plan's price). These events carry no name, email address or account identifier; like any request to Meta, they include your IP address and browser details, and the pixel sets the _fbp cookie (and _fbc if you arrived from a Meta ad). If you ALLOW targeting cookies, our server also sends the same events to Meta with your email address and name in irreversibly hashed form (SHA-256), a pseudonymous identifier derived from your account, the _fbp and _fbc values and, when the step happens in your browser, your IP address, browser details and the page address, so Meta can match them to its users more accurately. If you REJECT targeting cookies, the pixel is not loaded, its cookies are deleted and nothing is sent. You can change your choice at any time from “Cookie settings”. For what Meta does with data for its own purposes, Meta's privacy policy applies. The Meta Pixel is NOT loaded on the avatar page embedded in a storefront or on businesses' agent links.

Visits from our ads: when you arrive on agenola.ai from one of our Meta ads, the page tells our server how the visit went: the campaign, ad and placement in the link, whether the device is a phone or a computer, whether it opened in the Facebook or Instagram app, whether the browser reports automation, how long the page was visible, how far it was scrolled and how many times it was touched. We keep no IP address, cookie or other identifier with it, and nothing is stored on your device; we use it only to see which ads bring real visitors.

Where you came from: when you create an account, we keep with it the campaign tags in the address you arrived with (utm tags), the page you first opened and the site you came from, so we know which campaigns bring sign-ups; these don't identify you and no cookie is needed for them. If you allow performance or targeting cookies, we also remember them for 90 days in a cookie (agenola_attribution) together with the ad click identifier (fbclid or gclid), so they are not lost if you sign up on a later visit. With performance cookies allowed, our server also sends the same steps (sign-up, trial start, first store, subscription) to Google Analytics, linked to its _ga identifier. A one-day cookie (agenola_ad_events) lets the Meta Pixel report the same step our server reported, so it is counted once.

Functional cookies: they appear in the cookie settings, but the site does not use any cookies of this kind today. When we start using them, we will list the services here and ask for your permission again.

Sales attribution cookie (agenola_at): after a visitor has started a conversation with the agent, Agenola's storefront script sets this cookie on the store's own domain (a first-party cookie). It lasts 7 days, is set with SameSite=Lax and carries a signed reference to the conversation (workspace, agent, conversation and session identifiers); it contains no name, email address or other personal details. Its purpose is to recognise that an order placed within 7 days followed a conversation with the agent (sales attribution). It is set only if the visitor has allowed marketing cookies: on WooCommerce through WordPress's WP Consent API, on Shopify through Shopify's customer privacy API; if the store has no consent setup, consent is unknown and the cookie is never set.

Remembering the chat: When the agent is embedded in a store or a website, Agenola's storefront script writes three records to that site's own browser storage (first-party): the agent's session (valid for two hours), a reference that reopens the ongoing chat where it left off when the page changes (one hour), and references to the last 20 chats the visitor had on that site in that browser (“Chat history”; seven days after the last message). The references are random and do not contain the text of the chat. If the visitor is signed in to the store, the records hold their customer number at the store, and the session record also holds their name and email address. The chat itself is kept on our servers and can no longer be reopened seven days after the last message. Anyone using the same browser can open these chats; when someone signs in to or out of the store, the earlier chats are removed from the list so that another customer does not see them. The visitor can remove a chat from their chat history; this only removes it from the list in that browser, and the business keeps its record of the chat.

Cookies read at order time: when an order is paid, the store's plugin reads these first-party cookies if they exist and sends them to us with the order: _fbp and _fbc (Meta), _ga (Google Analytics), _ttp and ttclid (TikTok), _gcl_aw (Google Ads). Agenola does not set these cookies; the store's own analytics and ad tags do. They are read only so that the purchase event can be matched to the right visitor and ad click in the store's own account: their values are passed on only to the platform concerned and are not stored by us. On Shopify, with those permissions, Agenola's storefront script reads these cookies during the chat; they are kept in the conversation's run record on our server (at most seven days after the last message) and, when the visitor goes to checkout, in the cart as a property that is not shown, and they come back to us with the paid order. Their values are passed on only to the platform concerned.

Who we share it with

To provide the service we use these suppliers: a language model provider (produces the agent's reply, reads uploaded files when the agent asks for it, reads the text in images uploaded to the knowledge base, and builds the agent when you describe it in the panel), a text search service (Microsoft Azure OpenAI: turns the text of knowledge base entries and the search queries the agent builds from the conversation into a numeric representation so they can be searched by meaning), a speech synthesis service, a speech transcription service, Stripe (payments), an email delivery service (password reset and invitation emails), a file storage service (Cloudflare R2: files uploaded during a conversation and files and images uploaded to the knowledge base are kept in data centres in the European Union; avatar files, profile photos and logos are served from public addresses) Cloudflare Turnstile (on the sign-up form it checks in the browser that the visitor isn't a bot; Cloudflare receives the browser's details and IP address for this check only) and our hosting provider.

These suppliers receive only the data needed to do the job and are not allowed to use it for their own purposes. We do not sell or rent your data. We share it for advertising only with Meta, as described under “Cookies and measurement”: your name and email address only with your permission.

The business's own measurement platforms: if the business that built an agent turns on Google Analytics, Meta Pixel, TikTok or Google Ads in the agent's Measurement settings, events from the conversation (for example conversation started, contact details left, conversation completed, a step reached) are sent to that business's own account on the platform it chose. Events carry a pseudonymous visitor identifier derived from the session (not the session itself), the agent's name and the event's details (for a product search, the search term; for an event step, the values the business set). For Meta, TikTok and Google Ads, an email address and phone number the visitor left are sent only in irreversibly hashed form; these platforms also receive the ad click identifier recorded when the visitor arrived from an ad, and Meta and TikTok also receive the visitor's IP address, browser details and the address of the page where the chat was opened. If the business adds a step that adds visitors to a Google Ads customer list, the visitor's email address or phone number is sent to that list only in hashed form. At those platforms the business is the controller of this data.

In sales attribution (on WooCommerce and Shopify stores; on Shopify only if marketing is allowed), an order matched to a conversation sends a “purchase” event to the platforms the business turned on, with the order value, currency and order id. Google Analytics receives the client id from the _ga cookie, Meta receives _fbp and _fbc, TikTok receives _ttp and ttclid, and Google Ads receives _gcl_aw; Meta, TikTok and Google Ads also receive the order's email address and phone number, only in hashed form, and Meta and TikTok also receive the IP address and browser details of the browser that placed the order. At those platforms the business is the controller of this data.

If a legal obligation arises, data may be shared with the competent authorities.

Retention

TO BE CLEAR: there is currently NO automatic deletion mechanism. Conversation records, transcripts and tickets are kept until you delete them or ask us to.

This also covers the conversations for building agents with AI and the files you attach to them; you can ask for their deletion at info@agenola.ai.

To have your data deleted, write to info@agenola.ai; your request will be carried out within a reasonable time. Billing records are kept for the period the law requires.

Your rights

You can ask to access the data we hold about you, to have it corrected or deleted, or to receive a portable copy. Send your request to info@agenola.ai.

If you are a visitor who talked to an avatar, first send your request to the business that built it; we process on its behalf and take instructions from it.

Security

Connections are encrypted with TLS, passwords are hashed irreversibly, and secret server keys are never stored in plain text.

No system is completely secure. If we become aware of a breach affecting your data, we will inform you.

Contact

Data controller: ElliSekiz LLC, 30 N Gould St Ste R, Sheridan, WY 82801, USA. Questions: info@agenola.ai.

Back to home