Privacy Policy

Upsurge is operated by ONECOMPASS LIMITED, a Cyprus private limited company registered under number HE 410135, with its registered office at Griva Digeni, 81, Marinos Court, Floor 1 & 2, 6043, Larnaca, Cyprus. In this policy, “Upsurge”, “we”, “us” and “our” refer to that company. Contact our privacy team at [email protected].

This policy explains processing associated with our website, merchant accounts, agreement and privacy-notice acknowledgment records, support, billing, and the e-commerce services merchants connect to their stores. It covers individuals in the European Union and European Economic Area (EEA), as well as other people whose information we handle.

We act as a controller when deciding how to use account, business-contact, billing, security and support information for our own business purposes. For storefront information handled to provide a merchant’s chosen service, that merchant normally determines the purposes and we act as its processor under a data-processing agreement. If the merchant acts for another controller, we may act as a subprocessor. Merchant privacy notices explain their own purposes, legal bases and integrations.

Shared intelligence or identity processing can involve additional purposes and controller responsibilities. It is described separately below; a processor agreement alone does not authorize independent reuse of shopper data.

The combination collected depends on the features and integrations a merchant enables. Ordinary page URLs, referrers and custom event properties can contain personal information. Merchants should exclude sensitive URL parameters and unnecessary personal information before sending events. Do not submit payment-card numbers, passwords, health information, special-category data or criminal-record information in events, prompts, chats or uploaded content.

The public analytics ingestion path derives coarse country information only when its analytics-consent signal is present and does not retain the IP address in that analytics location field. This is not a promise that all infrastructure or security logs exclude IP addresses.

• Account and business details: name, email, company, store domains, account and team identifiers, roles, preferences, authentication and session records. These come from you, your organization’s administrator or the sign-in service you use.
• Commercial and billing records, where applicable: business contact and address, tax information, agreed plan, subscription, invoice and payment status associated with any agreed paid services.
• Storefront activity: page URLs and titles, referrers and campaign parameters, product views, searches, cart and checkout activity, purchases, order values, overlay and recommendation interactions, quiz answers, experiment assignments, and engagement summaries such as scrolling and time on a page. Sources include the merchant’s browser integration, server events and connected commerce systems.
• Identifiers and device context: device, visitor, session and merchant-provided user IDs; browser, operating system, screen dimensions, language and time zone; and, when enabled, a browser fingerprint. Some identity features use hashed identifiers. Hashing or replacing a name with an ID does not necessarily make the information anonymous.
• Customer records: names, email addresses, phone numbers, external customer IDs, order and spending history, audience memberships, recent activity, consent and suppression records, and inferred interests or predictions. Merchants may import these from their commerce platform, submit them through APIs or collect them through campaigns.
• AI and support content: chatbot and merchant-assistant messages, prompts, outputs, uploaded documents and images, knowledge sources, relevant product/cart/customer context, support handoffs, and records of tool actions and generated content. Where a merchant lets its team answer in the chat, a visitor who asks for a person opens a support ticket holding the conversation, the team’s replies, the ticket’s status, priority and assignee, the page and language where it was opened, and when the visitor last saw a reply or closed the chat or page. Visitors, merchants and connected systems supply this information.
• Support reply email: in such a conversation a visitor may give an email address to receive team replies they have not seen in the chat. Giving it is optional. It is used only to email replies in that conversation, through Twilio SendGrid under the store’s name; it is not shown to the merchant’s team and can be removed in the chat at any time. Records of each reply email, including a hashed form of the address, are kept with the ticket. If an address bounces, it is deleted and a hashed form is kept so that it is not used again for that conversation.
• Integration and operational records: connection credentials or tokens, permissions, workflow inputs and outputs, delivery and synchronization records, troubleshooting information, request metadata and audit logs. Network services receive IP addresses for connection delivery and security, including abuse prevention and rate limiting.

For processing where we act as controller, we identify a purpose and legal basis rather than treating acceptance of this policy as consent to everything. The following bases apply under Article 6 GDPR, subject to the particular relationship and circumstances.

• Provide an individual subscriber’s account and requested services, answer pre-contract requests and administer payment: performance of a contract or steps you request before a contract (Article 6(1)(b)). Required account and payment information is necessary to supply the requested service; without it we may be unable to do so.
• Manage corporate accounts and communicate with their staff: our legitimate interests in administering business relationships and supporting authorized users (Article 6(1)(f)). An employer’s contract does not itself make each employee a party to that contract.
• Protect accounts, investigate abuse, diagnose service faults, and establish or defend claims: legitimate interests in secure and reliable services and protecting legal rights (Article 6(1)(f)), balanced against individuals’ rights and reasonable expectations.
• Maintain legally required accounting records and respond to binding legal obligations: compliance with the applicable legal obligation (Article 6(1)(c)).
• Optional marketing and non-essential tracking where consent is required: your freely given, specific consent (Article 6(1)(a) and applicable electronic-communications rules). You can decline or withdraw without losing unrelated service functionality. Any permitted business marketing based on legitimate interests remains subject to an unconditional right to object to direct marketing.
• Process a merchant’s shopper data for analytics, search, personalization, campaigns, chat or workflows: the merchant determines and documents its legal basis. We process on its documented instructions under the applicable data-processing agreement; our contract with the merchant does not replace a lawful basis for its shoppers.

Upsurge uses cookies and browser storage for sign-in, preferences and storefront features. Non-essential analytics, attribution, advertising and fingerprinting require prior consent where applicable under EU national laws implementing the ePrivacy Directive. A merchant must explain each purpose and provider and offer an accessible way to refuse and later withdraw consent.

Consent controls: SDK version 3 starts with analytics, personalization, marketing and fingerprinting permissions off. The integration must pass a separate affirmative choice for each purpose before the corresponding processing starts. Analytics consent alone does not authorize personalization, marketing or fingerprinting. The updated server also rejects browser analytics events without an affirmative analytics signal and gates profile and workflow processing by the additional purposes they require. These controls apply to SDK version 3 and the current integrations. Merchants must keep their installed integration up to date and configure their consent controls correctly.

Use the store’s consent controls to refuse or change your choices as easily as accepting them. The updated integration stops the affected optional processing when permission is withdrawn; merchants must connect their consent controls to that update and retain evidence of the choices obtained. You can also clear browser storage, but doing so does not erase information already received by a merchant or Upsurge and may reset your stored choices. For deletion of existing information, use the rights process below.

• Account and preference storage includes the authentication session cookie, the upsurge_locale preference cookie (up to one year), and local language/theme preferences. Actual authentication lifetime depends on the session configuration.
• After the relevant permission, storefront local storage can include upsurge_device_id and, after identification, upsurge_user_id. The version 3 integration uses temporary in-memory identifiers before permission for persistent storage. Local storage has no automatic browser expiry; it remains until cleared or reset. Optional fingerprint-derived identifiers are refreshed after seven days; refresh is not a promise of deletion of server-side records.
• Session storage includes session IDs, acquisition details, experiment assignments, cart context, attribution state and workflow state. A logical SDK session normally times out after 30 minutes of inactivity; browser session storage generally lasts for the tab session and may be restored by the browser.
• Fingerprinting is off by default and requires both merchant enablement and a separate affirmative fingerprinting permission in the updated integration. When used, the fingerprint library may also contact its vendor’s infrastructure. Do Not Track support is configurable and is not enabled by default; do not assume a browser signal alone blocks collection.

Recommendations, Smart Search, audience rules and customer insights can use activity, purchases and inferred interests to rank products, group customers, measure campaigns or estimate outcomes such as churn, next purchase or customer lifetime value. These inferences can be inaccurate. Merchants decide how to use them and should offer the choices described in their own privacy notices.

AI chat and content tools may transmit messages, relevant conversation history, retrieved knowledge, product information and permitted customer/cart context to the model provider. The current chatbot uses Google’s Gemini services; other AI features or merchant-connected workflows can use Google, OpenAI or Anthropic. Outputs and tool actions may be stored with the conversation or workflow. Connecting an external assistant can also allow data access or actions within the permissions you authorize.

Upsurge includes consent-scoped identity and shared-intelligence capabilities. Cross-store matching and reuse for shared signals require a separately established purpose, lawful basis, appropriate notices and any necessary consent. These capabilities must not be treated as anonymous merely because they use hashed or pseudonymous IDs. Before enabling them, the parties must establish their respective controller/processor roles and the specific disclosures and controls.

Customer-profile prediction models are trained per merchant. A separate platform identity graph can maintain platform-scoped hashed identifiers; configured platform exports can forward consent-scoped identity and intent events. Platform exports are enabled in the serving staging and production environments. RudderStack processes these events in its US production region, with sample-event storage enabled for a rolling 30 days. The shared stream remains enabled. Its purpose and role assessment and end-to-end withdrawal/deletion verification remain outstanding and have been deferred; this policy does not represent those checks as complete or authorize additional processing. Contact our privacy team about requests affecting this stream.

Google’s published Gemini terms distinguish service and billing arrangements. Its paid-service data-use terms do not permit use of prompts or responses to improve its products, but its published abuse-monitoring policy describes 55-day retention and some features have additional storage rules. Vertex AI has separate feature-specific rules. Current generation uses the direct Gemini API; knowledge embeddings use that API with a Vertex AI fallback, while product embeddings use Vertex AI in the US. The reviewed source does not enable Files, explicit caching, Interactions, Live or grounding features. The deployed Gemini keys have been matched to billing-enabled projects, and the production project is on a paid tier. Direct Gemini processing is not limited to the Vertex AI region. This policy makes no blanket promise of zero retention or identical model-training terms across providers. Applicable provider contracts, account settings and the data sent must be verified for each enabled feature. The data-processing addendum limits processing on a merchant’s behalf to authorized purposes; independent model training or unrelated reuse requires a separate lawful arrangement.

The service is intended for commerce assistance and optimization. Merchants must not use it to make solely automated decisions producing legal or similarly significant effects on individuals without the safeguards required by law, including any applicable right to human intervention and to contest the decision.

Google Gemini API terms

Google Gemini abuse-monitoring policy

A list of tools supported by the product is not a list of subprocessors actually receiving your data. The data-processing schedule identifies the service providers, purposes, known processing locations and transfer arrangements, including outstanding verification limitations. Contact the privacy team for information about a particular service or connection.

• Authorized staff and service providers that help deliver hosting, authentication, databases, storage, analytics infrastructure, AI processing, communications, monitoring and support. Our service providers include Google Cloud/Firebase, Google Gemini, Cloudflare R2, Dash0, Typesense Cloud, RudderStack and Twilio SendGrid. ONECOMPASS has confirmed that it uses these services under company accounts and has accepted their data-processing terms. Which provider receives a particular person’s data depends on the feature, account settings and data sent. The AI processing paths and location distinctions are described above and in the data-processing schedule.
• The merchant operating a storefront and its authorized team members, who can access customer information, reports, conversations and campaign or workflow records within their permissions.
• Providers a merchant or user connects, such as commerce platforms, advertising and attribution services, email services, support systems, spreadsheets, messaging services, webhooks and external AI assistants. Some act for the merchant, some for us and some as independent controllers; their own notices and contracts also apply.
• Professional advisers, authorities or other recipients where necessary to comply with law, investigate unlawful conduct or protect legal rights. In a corporate transaction, relevant information may be disclosed subject to appropriate confidentiality and data-protection arrangements.

Upsurge’s operator is in Cyprus, but that does not mean every service or database is hosted in the EEA. The 11 October 2026 infrastructure review confirmed US-based Firestore databases and primary application/storage services in staging and production. Attribution warehouse datasets are in the EU, while identity-graph datasets are in the US. Production Typesense search indexes are hosted in Frankfurt, Germany; staging search indexes are in Northern Virginia, United States. RudderStack uses its US production region. Cloudflare R2 stores our static SDK assets in Eastern North America. Dash0 monitoring uses Google Cloud’s Netherlands region. SendGrid uses its global service rather than an EU-specific endpoint. These service locations do not by themselves determine every support or onward-processing location. Provider support, AI services and merchant-selected integrations can involve additional countries. There is no EU-only hosting commitment.

A transfer subject to GDPR Chapter V requires an applicable adequacy decision or appropriate safeguards, such as the European Commission’s Standard Contractual Clauses, with assessment of the transfer and supplementary measures where needed. This policy does not assert that a particular vendor is certified under a framework, that all transfers are covered by executed clauses, or that EU-only hosting is provided.

The processing schedules record the relevant destinations and applicable safeguards. Outstanding verification of the shared RudderStack stream remains separate; publication or acknowledgment of this notice is not proof that those checks are complete. You can contact the privacy team to request information about the applicable safeguards and a copy, with necessary redactions to protect confidential information.

Retention must be limited to what is necessary for the purpose. Account information is needed while the account is in use and for an appropriate period to resolve support, security or legal matters. Billing records may need to be retained for applicable accounting and tax obligations. Retention after a dispute or legal hold is limited to the records necessary for that obligation.

For merchant-controlled data, the processing agreement and a verified retention schedule must define how long each category remains in active stores, logs, analytics systems and backups, and what happens when the service ends. Deleting an account or a browser identifier does not necessarily delete every related record.

Chatbot retention schedule: sessions, stored model threads and messages expire 180 days after session creation; tool audits, discount actions and handoffs after 365 days from their creation; turn observations and evaluation records after 90 days from creation; and completed, failed, cancelled or otherwise terminal knowledge-ingestion and product-embedding jobs after 30 days from completion. Activity does not renew a session deadline. Source controls enforce expiry on relevant reads and writes and provide cleanup. Hourly cleanup and database expiry rules enforce these periods; historical cleanup is verified at deployment. Current knowledge sources and pending or processing jobs are outside that terminal-job schedule.

Support inbox records follow the chatbot conversation they belong to: support tickets, their messages and reply-email records expire with its session, no later than 180 days after the session was created. A visitor’s reply email address is deleted when the visitor removes it, when it bounces or when the ticket expires. Merchant-authorized customer erasure deletes the support records of conversations linked to that customer and removes the customer’s email address, including the hashed form kept after a bounce, from the merchant’s tickets. Reply-email records keep a hashed form of the recipient address until they expire with the ticket.

Warehouse retention is category-specific: attribution history uses 90-, 120- or 763-day windows and profile-feature history uses 400 days. Daily cleanup removes expired intent traits and identity links, unneeded identifiers after 400 days of inactivity, completed privacy-request payloads after 90 days, accountability history after 25 months, and model history after 763 days. Active consent denials, suppression controls, unresolved privacy work and documented legal holds remain only while needed for their protective purpose. Daily scheduled cleanup applies these rules in production. Analytics archives use 90- or 763-day lifecycle rules followed by seven-day soft deletion. Rolling analytics snapshots have an eight-day retention policy; the retired manual recovery exceptions have been removed. BigQuery deletion remains subject to its configured time-travel window and a further seven-day fail-safe period. Dash0 monitoring and selected RudderStack sample events have 30-day retention. Provider-specific security logs, backups and termination periods can differ. Merchant-authorized erasure covers records reliably linked to the customer and store; unlinked records and copies held by other systems require coordinated handling. Contact the privacy team or the merchant for the applicable criteria, deletion process or any documented exception.

Depending on the processing and the conditions in the GDPR, you can request:

• Access to your personal data and information about its processing; correction of inaccurate or incomplete data; erasure; and restriction of processing.
• A portable copy of data you supplied where processing is automated and based on consent or a contract, and transmission to another controller where technically feasible.
• An objection to processing based on legitimate interests because of your circumstances. You can object to direct marketing, including related profiling, at any time without giving a reason.
• Withdrawal of consent at any time, without affecting the lawfulness of processing before withdrawal. Withdrawal must be as easy as giving consent.
• The protections applicable to solely automated decisions with legal or similarly significant effects, including human intervention and the ability to express your view and contest a decision where applicable.

Cyprus Commissioner for Personal Data Protection

Email [email protected], or write to our registered address, identifying your relationship with Upsurge and the information concerned. For storefront data, include the merchant or store domain; the merchant is usually the controller. You may contact that merchant directly. Where we act as processor, we assist it with your request and do not independently decide its response.

We may request proportionate information to verify identity or authority. Do not send identity documents or sensitive information unless requested through an appropriate channel. Requests are normally free. GDPR permits a reasonable fee or refusal for manifestly unfounded or excessive requests, with an explanation.

Where we are responsible for responding as controller, we respond without undue delay and ordinarily within one month of receipt. If complexity or the number of requests requires an extension, we may extend by up to two further months and will explain the reasons within the first month. If we cannot act on a request, we will explain why and how you can challenge the decision.

You can complain to the Cyprus Commissioner for Personal Data Protection or to the supervisory authority in the EEA country where you habitually live, work or believe an infringement occurred. You do not need to contact us first. Your rights to judicial remedies remain unaffected.

Email the privacy team

The service includes authentication, permission checks, scoped access and protections for selected sensitive records. No online system can guarantee absolute security. Measures and responsibilities applicable to merchant data must be documented in the data-processing agreement and verified for the deployed services.

Merchant accounts are for adults acting for a business. The service is not designed for collecting children’s data or targeting children. Merchants must assess their audience, applicable age rules and any parental-consent requirements before enabling features. Contact us if you believe a child’s information has been submitted improperly.

When an effective version is adopted, its date and version will be stated here. Material changes will be communicated in a manner appropriate to their significance. Where a new purpose requires consent or further notice, an updated policy alone will not supply that consent or replace the required notice.