Privacy Policy

Clickalong is a customer-support platform operated by Profitonium Apps Ltd (“Clickalong”, “we”, “us”). This policy explains what personal data we collect, why we collect it, and the choices you have. Questions go to hello@profitoniumapps.com.

Who this policy is for

We serve two groups. Operators are the businesses and their team members who sign up to run a support workspace. Visitors are the end customers who talk to an operator through the Clickalong widget on that operator’s website. When a visitor uses the widget, the operator is the controller of that conversation and we process it on their behalf.

What we collect

• Account data. When an operator signs up, our authentication provider (Clerk) stores a name and email address and manages the login. We do not see or store passwords. To secure authenticated sessions, Clerk also processes session activity such as IP address, IP-derived city and country, browser name and version, and device type. Chrome Web Store reviewers use a confidential, expiring access code that is sent only to Clickalong’s first-party credential broker. We compare its SHA-256 verifier, never store or log the raw code, exchange it for a five-minute single-use Clerk ticket, and immediately discard both values after sign-in.
• Operational request data. When the web app or Chrome recorder calls Clickalong, Cloudflare necessarily processes the request IP address, which can indicate an approximate location. Cloudflare may also write bounded invocation logs containing the request method and URL, response details, timestamp, and related metadata. We use this information only for security, abuse prevention, troubleshooting, and service reliability.
• Workspace content. Support conversations, help documents, saved replies, guided-tour steps, and workspace settings that operators create.
• Chrome recorder data. When a signed-in operator explicitly starts the Clickalong Recorder extension, an otherwise inert content script activates only in that recording’s bound tab. Each trusted primary click continues into the operator’s app normally and immediately appends a tour action. The action includes a CSS selector with safe fallback locators, a short visible or accessibility label, target geometry and coordinates, the clicked frame’s origin, and a sanitized pathname. Query strings, fragments, signed parameters, and another frame’s URL are not retained. For each retained click, the extension captures the full visible tab and downscales it to a JPEG no larger than 1600 pixels on its longest edge. This is a viewport screenshot, not a target crop. Any content visible in the tab, including a visible field value, personal message, financial detail, or content outside the clicked frame, may therefore appear in the image. The extension does not scan form fields or marked private regions to hide or blur those pixels. It also makes a best-effort sanitized static HTML snapshot of the clicked frame. The snapshot preserves useful structure and visible text but removes executable JavaScript, event handlers, styles, form submissions, executable or signed URLs, entered values, password, hidden and file controls, active embedded content, recorder-owned controls, and marked private subtrees. Apart from pixels already visible in the screenshot, the extension never reads entered form values through page APIs; it also never reads cookies, browser storage, or clipboard contents. Screenshots and HTML upload as authenticated requests to private Clickalong storage as they become available. IndexedDB retains the only local copy until the server confirms an upload; confirmed bytes are then removed locally. HTML is best-effort and never blocks Finish. Every retained action requires a ready screenshot. Deleting an action or cancelling a recording deletes its artifacts. A new tour publishes on Finish; replacing an existing tour creates a protected dashboard draft while the current live tour remains unchanged.
• Visitor data. The messages a visitor sends, and technical context that helps an operator answer: approximate location (country and city derived from IP), language, the page the visitor is on, and coarse network information such as ISP. A visitor only shares an email address if they choose to type one in. An operator may verify that identity with a server-generated one-way HMAC hash. The workspace identity secret used to create the hash stays with the operator and is never sent to the visitor’s browser.
• Lead form data. If a workspace enables an optional lead form, a visitor can choose to submit contact details and custom answers to that workspace’s support team. Clickalong stores those answers as a separate lead record; they are not added to visitor attributes or to AI context. Contact details entered in the form are self-reported unless the submitted email exactly matches an identity the operator’s server already verified, in which case the record is labelled host-verified. The widget may offer a configured external booking page only after the lead has been saved. Clickalong does not book an appointment, embed that site, or append submitted details to its link.
• In-app assistance context. When a visitor chooses Show me, Take me there, or Do it for me, the widget builds a bounded, temporary semantic index of the current app page, including below-fold controls, open shadow roots, and same-origin frames. It may contain sanitized accessible labels, roles, element types, landmarks or nearby headings, control state, same-origin frame paths, visibility, and a query-free route path. It excludes screenshots, raw HTML, form values, contenteditable contents, cookies, browser storage, authentication material, cross-origin frames, marked private regions, email addresses, record-like IDs, and number-like personal data.
• Registered action metadata. An operator can give the widget a bounded list of explicitly supported host actions. Clickalong receives only the sanitized action ID, title, description, create/update/send effect, and primitive parameter schema. The executable callback remains inside the operator’s app. Action arguments and a callback’s raw result are used only for the active visitor-initiated run and are not stored by Clickalong.
• Assistance audit events. We retain a text-free operational trail for task safety and workspace audit. It contains fixed event and status codes, trusted source and registered-action identifiers and titles, action effect, confirmation/result status, locator method, a sanitized route, error code, and timestamps. It does not contain page labels or contents, action arguments, visitor clarification values, callback functions, or raw callback results.
• Tour diagnostics. When a visitor runs a guided tour, we record technical events such as tour started, target found or missing, step advanced, exited, and completed, together with the tour version and step number. This lets workspace operators find broken targets and drop-off points. These events do not contain typed field values or screenshots.
• Answer delivery diagnostics. To measure and improve reply speed and reliability, the widget reports bounded elapsed times to the first status, first visible text, and final painted state, together with server-generated request and message identifiers, a fixed outcome code, and whether page visibility changed while waiting. This diagnostic record does not include message text, page URL, request IP address, browser user agent, or session identifier.
• Cookies and acquisition context. A session cookie keeps operators signed in and remembers the last workspace, with additional authentication cookies set by Clerk. Before a first workspace is created, a first-party cookie may retain bounded UTM campaign fields, an allowlisted public landing path, and an external referrer origin for up to 30 days; referrer paths and query strings are discarded. That first-touch context is then attached to the workspace. Optional marketing analytics do not load unless you choose Allow analytics. A refusal is stored only in your browser, and a browser Global Privacy Control or Do Not Track signal suppresses both the prompt and the analytics runtimes. If allowed, we use Google Analytics and Cloudflare Web Analytics on our public marketing pages, including blog and comparison pages, to understand aggregate traffic and page performance. Neither runs in the dashboard, authentication pages, invitation pages, API routes, or customer help centres.

How we use it

• To run the service: showing tours, generating AI answers, and routing conversations.
• To send operational email you would expect (see below), and to keep the service secure and prevent abuse.
• To understand and improve how the product is used, in aggregate.

AI answers are generated by sending the relevant workspace documents, the current conversation, and saved guided-tour names and descriptions to DeepSeek. Tour names and descriptions let the assistant match a visitor’s question to a useful tour; step selectors, screenshots, HTML snapshots, and recorded coordinates are not sent to the models for that matching. If DeepSeek cannot produce an answer, the same context may be sent to OpenAI as a fallback. We do not sell personal data. These providers process the content under their applicable terms and privacy policies.

If a visitor starts in-app assistance, a bounded provider chain may also receive the trusted tour or document instructions, the temporary sanitized page index and action manifest, and any non-sensitive primitive clarification supplied for that run. For that planning step the chain may begin with Google Gemini (reached through OpenRouter, which we restrict to endpoints that do not store or train on request content) or Cerebras before falling back to DeepSeek and OpenAI. Clickalong validates the complete plan before acting. Page indexes, clarification values, action arguments, and raw callback results are ephemeral and are never written to our database.

Email

We send transactional email only: workspace invitations, conversation transcripts to a visitor who asked for one, and notifications to operators about their own conversations. Every transcript includes an unsubscribe link, and operators can turn off their notifications in settings. Email is sent through Cloudflare Email Sending with SPF, DKIM, and DMARC authentication. We do not send marketing email without separate, explicit opt-in. We do not send lead-submission email to the submitted address; a visitor receives email only through a separate, explicit conversation or transcript flow.

Who we share it with

A workspace administrator may optionally connect Slack or Zendesk for outbound escalation handoff. When enabled, Clickalong sends the visitor label, bounded escalation message, safe page path, conversation link, and a stable event identifier to the customer’s selected destination. Slack and Zendesk replies are not imported into Clickalong. Integration credentials are encrypted separately from workspace content and are removed when the administrator disconnects the integration.

A workspace administrator may also configure signed HTTPS webhooks for selected message, lead, and escalation events. Clickalong sends a bounded event snapshot to the URL the administrator supplies. Message events can contain the message text; lead events can contain submitted contact details. Private operator notes, IP and ISP fields, authentication material, assistance callback data, and user-defined headers are excluded. Each endpoint has a signing secret that is shown only when created or rotated; Clickalong stores only its digest and hint. We do not read or retain the receiver’s response body.

A workspace administrator may also connect one or more explicitly selected Notion page trees, including bounded database entries, or GitHub repositories as knowledge sources. Each connection remains isolated. Clickalong sends the saved server-side credential only to the provider’s official API, reads the selected page tree or matching repository files, and stores the extracted text as workspace documents. Notion and GitHub tokens are encrypted separately from document content and removed on disconnect. Previously imported documents are retained after disconnect, stop refreshing, and remain editable; a manual title or body edit permanently detaches that document from connector control. We do not follow links found inside Notion content or fetch GitHub raw-content URLs.

We use a small set of subprocessors to run the service. Current purposes and processing locations are maintained in our subprocessor register:

• Cloudflare: hosting, database, file storage, transactional email delivery, privacy-first marketing-site traffic and performance analytics, and authenticated AI Gateway routing. AI Gateway request and response collection is disabled, so Cloudflare does not store prompt or response payloads in Gateway logs.
• Clerk: operator authentication.
• DeepSeek: primary AI answer generation.
• OpenAI: fallback AI answer generation.
• Cerebras: in-app assistance planning.
• OpenRouter and Google (Gemini): in-app assistance planning, restricted to endpoints that do not store or train on request content.
• Google Analytics: marketing-site analytics.
• MongoDB Atlas and Voyage AI: optional semantic passage indexing and embeddings.
• Stripe: hosted subscription checkout and billing.

We share data with these providers only to the extent needed to run the service, and we may disclose data if required by law.

Chrome Web Store Limited Use

The Clickalong Recorder’s use of information received from Google APIs adheres to the Chrome Web Store User Data Policy, including its Limited Use requirements. Information obtained through Chrome extension permissions is used only to provide or improve the recorder’s user-facing tour-creation, delivery, and matching features. We do not sell it, use or transfer it for personalized advertising, or use or transfer it to determine creditworthiness or for lending purposes. We do not allow humans to read it except with the operator’s explicit consent for support, when necessary for security or legal compliance, or after it has been aggregated and anonymized for internal operations.

Retention

We keep workspace content for as long as the account is active. Terminal signed-webhook delivery records and their immutable event snapshots are pruned after 30 days; pending deliveries remain until delivered, failed, suppressed, or administratively resolved so a temporary outage cannot silently discard an event. Delivered transactional email records, automation logs, accepted or revoked invitations, and long-expired pending invitations are pruned after 30 days. Per-step tour diagnostics are pruned after 90 days. Answer delivery diagnostics are pruned after 90 days. In-app assistance runs expire after 30 minutes; incomplete run state is pruned after 24 hours, and the text-free assistance audit events described above are retained for 90 days. Cloudflare Workers invocation logs are retained for no more than seven days. Waitlist entries collected during our early-access period are retained as sign-up records and are removed on request. Abandoned Chrome recordings expire after two hours and are pruned automatically. A protected replacement draft expires after 14 days if it is not published. Saved recording actions, screenshots, and HTML snapshots follow the saved tour’s workspace-content retention period; deleting an action, cancelling a recording, discarding a replacement draft, or replacing or deleting a tour removes artifacts it no longer uses. Ordinary workspace deletion creates a retained tombstone: it immediately disables public access and ordinary processing but keeps workspace records and primary content for internal diagnosis and legal or billing integrity. A customer may make a permanent deletion request at the contact below; after validating the request and applicable retention duties, we delete or anonymize eligible data within a reasonable period.

Security

Data is encrypted in transit, and Cloudflare encrypts D1 and R2 data at rest with provider-managed keys. Access to production systems is restricted, and each workspace is isolated so operators only reach their own data. Chrome grants the recorder access to HTTP and HTTPS sites at installation so it can survive navigation and record embedded frames. The installed content script performs no capture or network request outside a recording explicitly started by a signed-in operator, and the background worker accepts actions only from that recording’s bound tab. Before taking a visible-tab screenshot, the worker verifies that the bound tab is active and its window is not minimized so pixels from another page cannot be attached to an action. Saved screenshots use server-owned private asset IDs and are served only after widget authentication. Authentication tokens remain in trusted extension contexts and are never passed to the recorded page. No system is perfectly secure, but we work to protect your data and to fix issues quickly.

Your rights

Depending on where you live, you may have the right to access, correct, export, or delete your personal data, and to object to certain processing. To make a request, email hello@profitoniumapps.com. If you are a visitor, you can also contact the operator whose widget you used, since they control that conversation.

International transfers

Our providers may process data in countries other than your own. Where that happens, we rely on those providers’ safeguards for lawful international transfers.

Children

Clickalong is not intended for anyone under 16, and we do not knowingly collect their data.

Changes

We may update this policy as the product changes. We will post the new version here and update the date at the top. Material changes will be communicated to operators by email or in the app.

Contact

Profitonium Apps Ltd · hello@profitoniumapps.com