Privacy Policy

1. Data we collect on each click

When a visitor resolves an OrcLink short URL, we record:

• A salted hash of the IP address and of the user-agent string. The raw IP is used only while the request is handled (to look up country and city, and for rate limiting) and is not stored.
• Parsed device type, operating system and browser name.
• The referring URL, if the browser provides one.
• Approximate location (country, city), looked up from the IP at request time.
• A visitor identifier in theLo_vidcookie. On a visitor's first click it is derived from a daily hash of IP address + user agent (a fingerprint fallback, used only until the cookie exists). The cookie is set on every redirect; it is not gated by a consent banner (see section 3). The visitor id stays on our servers: we never put it in a destination URL, a cart or an order. Workspaces in strict consent mode (for regulated businesses) get no visitor cookie, no fingerprint and no visitor profile: each click stands alone, and we store neither the IP hash nor the user-agent hash, and of the location only the country.
• A click id (olid) for every click that is not a bot. It is a random id (ol_ plus 32 characters) that identifies the click record. We add it to the destination URL so a later order can be matched to the click. On a merchant custom domain we also store it in the orc_olid cookie for 90 days (1 day in strict consent mode). Our store scripts never extend that cookie: the capture script writes a new click id for 90 days (1 day, with no localStorage copy and only a session-long orc_sid, in strict consent mode), and the Shopify pixel and app write it for 1 day on every store.
• If the link URL carries an ad click id (fbclid, gclid, gbraid, wbraid, ttclid, li_fat_id, msclkid, oppref, rdt_cid, epik, twclid, ScCid): that id, the UTM parameters, the full user-agent string and the destination URL. We need these to report the conversion back to the ad platform. Such clicks get the same click id (olid) as any other. The ad click ids are also passed through to the destination URL so the store's own pixels still see them. In strict consent mode we store no user-agent string and no IP hash: a link click keeps the click ids (the ad click id and theolid), the UTM parameters, the destination URL and the country. An ad click that the capture script (/t.js) records on the merchant's site keeps the click ids, the session id (orc_sid, a session cookie in strict consent mode; where the script follows a consent manager, only with analytics consent), the Meta and TikTok browser ids (_fbp, _ttp) when those cookies exist, the user-agent string (not in strict consent mode), the UTM parameters (a value that looks like an email address or phone number is replaced), the landing page address without its query string (parts that look like an email address, a phone number or a long token are replaced; in HIPAA mode only the site address) and the country. Where the script follows the consent manager on the page, it records an ad click only after advertising consent (section 3). When a visitor refuses, or their browser sends Global Privacy Control, the script records nothing for that visitor and adds nothing to forms, with the one limit described in section 3 (a consent manager that appears late).

2. How we use it

• Resolving the link to its correct destination.
• Counting clicks and attributing conversions back to the workspace that owns the link.
• Deriving a coarse visitor intent signal (Discovery / Considering / Ready to Buy / Fan) used to personalize which destination a link resolves to.
• Reporting conversions to the ad platforms the workspace connects (see section 5).
• Rate-limiting abusive traffic.

3. Cookies and browser storage

OrcLink has several components, and they behave differently. The table below lists every cookie and storage key any of them writes, on any domain. It is generated from the same list our code is tested against.

On orclink.com, the consent banner controls the optional analytics, personalization and marketing categories. The link redirect and the Shopify pixel do not wait for a consent banner; merchants who need consent before these run must load them through their own consent manager. The first-party capture script (/t.js) reads the consent manager on the merchant's page (CookieYes, OneTrust, Cookiebot, Google Consent Mode, IAB TCF) and treats a Global Privacy Control signal as a refusal, unless the merchant turned this off. It has two separate gates. Analytics consent (Google Consent Mode analytics_storage, CookieYes analytics, OneTrust C0002, Cookiebot statistics, IAB TCF purpose 1) lets it record visits and keep the session id (orc_sid). Advertising consent (Google Consent Mode ad_storage and ad_user_data, CookieYes advertisement, OneTrust C0004, Cookiebot marketing, IAB TCF purposes 1 and 7) lets it record ad click ids and the Meta and TikTok browser ids, keep the click id (orc_olid), add the hidden click-id field and capture forms. A visitor who allows analytics but not advertising is recorded as a visit with no click id; a consent manager that offers only one choice decides both. If Google Consent Mode never sets analytics_storage, the ad consent types that are set decide the analytics gate (any denied means denied). Until the consent manager answers, the script writes, sends and adds nothing; a consent manager that is still loading, or a Google Consent Mode setup that so far only sets wait_for_update, counts as no choice yet. When a visitor refuses, or their browser sends Global Privacy Control, the script records nothing for that visitor and adds nothing to forms. The one limit: if no consent manager shows up by 500 ms after the page has finished loading (or 5 seconds after the script started, if the page takes longer to load), the script decides the page has none and starts. A consent manager that appears later than that finds the script started: what the script wrote (cookies, storage and the hidden click-id fields) is removed once the script sees the consent manager without a yes (within seconds during the first 10 minutes, later at the visitor's next action), but requests already sent are not unsent. A withdrawal is honoured at the visitor's next action on the page (a page change, a form submit), also in single-page apps. The store personalization pixel (/pixel/v1.js) writes to storage only after consent, and treats a Global Privacy Control signal as a refusal.

Global Privacy Control and Do Not Track: a link click from a browser that sends Global Privacy Control is recorded as in strict consent mode (no visitor cookie, no visitor id, no IP address or user-agent hash), with no click-id cookie and no ad-click record, so no conversion is ever sent to an ad platform from that click. A browser that sends Do Not Track is treated the same, unless the business turned Do Not Track off. The capture script treats both signals as a refusal while it follows the page's consent manager (Do Not Track only while the business honours it); whatever the script does, a capture request that carries either signal records no ad click, adds nothing to an earlier click, records no visit and no form lead, and makes no cross-domain link.

On sites with more than one domain, a link from one of the merchant's verified sites to another carries the click id (after advertising consent) and a one-time, encrypted session code (after analytics consent, valid for 2 minutes, for that site only); the receiving site removes both from the address at once. A form inside a frame on a verified site can get the click id and session id from the page around it, only as far as that page's visitor consented.

A site can also pass two ids of its own with a visit:

• SiteSession.externalIdHash: A keyed hash (HMAC-SHA256 under a key derived from the deployment secret) of the workspace id and the site's own order or lead id. The id itself is not stored. An id that looks like an email address or a formatted phone number is refused. Sent by the capture script only after advertising consent, like orc.identify. Stored in strict consent and HIPAA mode too (a hash, no visitor id). Kept as long as the visit record.
• SiteSession.gaClientId: The Google Analytics client id the page passed (two numbers joined by a dot), stored only on a visit whose consent state is granted and only while the workspace is in neither HIPAA mode nor strict consent (checked in the write itself); turning either on clears every stored client id of the workspace at once. Sent by the capture script only after advertising consent, and never in strict consent or HIPAA mode. Kept as long as the visit record.

4. Store orders, site visits, form leads and calls

When a Shopify merchant connects their store, OrcLink writes the click id (olid) onto the cart as the Orclink_Olid attribute. It writes nothing else there, and the visitor id is never part of the cart or the order. Shopify sends us order webhooks, and we accept them only from a shop that is connected to a workspace. From those we keep the order id, number, value, currency, refunds and status, and a SHA-256 hash of the webhook body (not the body itself). If the order has an email address or phone number, we hash it (SHA-256) on arrival and keep only the hash; the raw value is not stored. No card data or address is stored. The same applies to conversions a merchant sends through the OrcLink API or its own Stripe account.

Other stores and billing systems.When a merchant connects WooCommerce, BigCommerce or Magento, the store sends us its orders (BigCommerce: we read the order from the store with the merchant's API token). The OrcLink plugin, module or checkout script copies the click id from the orc_olidcookie to the cart and the order, and clears that copy when the cookie is gone. When a merchant connects a billing system (Chargebee, Recurly, ChartMogul), it sends us paid invoices and refunds (Recurly: we read the invoice from Recurly with the merchant's API key). From orders and invoices we keep the same fields as for Shopify, plus, for a billing system, CanonicalOutcome.payerRef: A keyed hash (HMAC-SHA256 under a key derived from the deployment secret, with the workspace) of the billing system's subscription id, or its customer id when the payment has no subscription: a stable pseudonym of the payer in this workspace, never the id itself. Only on payments from a billing system (Chargebee, Recurly, ChartMogul, Xero). Tell a payer's first payment (sent to the ad platforms as a purchase) from their renewals (revenue only). A second subscription of the same customer is a new payer; a one-time charge is a purchase. Kept as long as the outcome: the workspace's retention setting, 90 days by default in HIPAA mode (24 months otherwise), then deleted with it.For a store we keep the store's address (one store per connection) and the store's own last-change time of each order (StoreOrderVersion, ids and a time, deleted after 90 days). Emails and phone numbers are hashed on arrival and never stored raw. Only a payer's first payment is sent to advertising platforms as a purchase; renewals are not.

Site visits.On a merchant site with the capture script, each visit is recorded: the page paths (without the query string), the host of the referring site, the campaign parameters in the address (utm_source, utm_medium, utm_campaign, utm_term, utm_content and ad click ids), the device class (mobile, tablet, desktop) and the country. Each visit gets a marketing channel (for example Google Paid, Email or Referral), worked out from these values and the merchant's own channel rules; a custom source parameter in the address (orc_source unless the merchant renamed it) is read only for that and is not stored. A visit by an AI assistant browsing for a person is marked as such; crawlers are not recorded. We never store the query string, the full address, the page title, the IP address or the user agent. Parts of a path that look like an email address, a phone number or a long token are replaced. Free text inside a page address (for example a name) is not detected: merchants use HIPAA mode, which stores no page addresses, when page addresses can identify a person. Visits are grouped by the session id (orc_sid). In strict consent mode visits are not grouped by it: the visit beacon carries no session id and visits are tied only to the click id (the session id then lives only for the browser session, and an ad click or a form lead can still carry it, see section 1). Visits need analytics consent where the script follows a consent manager: when a visitor refuses, or their browser sends Global Privacy Control, no visit is recorded, with the one limit described in section 3 (a consent manager that appears late). In HIPAA mode no page paths are stored; a visit keeps its source and campaign, device class, country and a page count. A merchant can turn visit recording off.

Form leads. A merchant can mark forms for capture. When a marked form is submitted, the capture script (/t.js) reads the first email field and the first phone field of that form, and nothing else, and sends them to OrcLink with the click id and the session id. We hash them (SHA-256) on arrival and keep only the hash; the raw values are not stored or logged. Where the script follows a consent manager, forms are captured only after advertising consent. When a click id is known (and, where the script follows a consent manager, after advertising consent), the script also adds a hidden field with the click id to the forms on the page, also to forms that post to other services (a CRM or a booking tool), so those services receive the click id. A merchant can exclude a form with data-orc-ignore. A merchant's own form or chat can also call orc.identify with an email address or phone number: it is hashed on arrival in the same way, only ties the hash to the click, and records no lead. None of this writes a new cookie or storage key.

Calls. When a merchant connects a call tracker (CallTrackingMetrics, CallRail, Invoca, Infinity, Delacon), it sends us each call. We keep a hash of the caller's number, its last 4 digits, the number that was dialed (the merchant's tracking number), the call times, duration and result, the call tracker's source label, a reference to the recording (its id or address, not the audio) and a SHA-256 hash of the webhook body. The full caller number is kept only when the merchant turns that on, and never in HIPAA mode; turning HIPAA mode on deletes the numbers already kept.

Call tracking with tracking numbers.If a business uses OrcLink call tracking, its website may show you a phone number that belongs to the business but was assigned to your visit (a "tracking number"). OrcLink stores the tracking numbers the business bought, and which number was shown to which visit and for how long (a "number assignment", tied to the visit record, not to you by name). Numbers are assigned only after you allow analytics on the site (or, on sites in strict privacy mode, only to a visit that came from an ad click), and never to search engines or AI agents. When you call a tracking number, the call is forwarded to the business by Twilio, under the business's own Twilio account; Twilio processes the call for the business. OrcLink stores a call record: the time, duration, result, the number you dialed, the visit it matches (if any), a one-way hash of your phone number and its last 4 digits. Your full phone number is not stored unless the business turned that on, which is not possible in HIPAA mode. If the business records calls, you hear a notice first; the recording stays with Twilio, OrcLink keeps only a reference to it, plays it only to the business's administrators, and deletes it at Twilio after the business's retention period (at most 85days). Call records, call state and number assignments are purged on the 90-day window; a number assignment is deleted with its visit. Counts of visitors who saw the business's own number (because all tracking numbers were in use, or a per-network limit was reached) are aggregate and kept 90 days; no IP address is stored for them. Call transcripts (CallTranscript) are made only when a workspace turns transcription on for a number pool, never in HIPAA mode, and only after the spoken notice says the call may be transcribed. The text is stored encrypted, shown only to team members who may play the recording, deleted with the recording, and included in a data-subject export or delete. A summary and a lead score are written only when the workspace has turned the AI agents on; the transcript is redacted of email addresses, phone numbers and hashes before it is sent.

5. Conversions sent to ad platforms

A workspace can connect Meta, Google, TikTok, LinkedIn, OpenAI Ads, Microsoft Ads, Reddit, Snapchat, Pinterest, X and CM360 / SA360. For a conversion we then send the ad click id, the Meta and TikTok browser ids (_fbp, _ttp; each only to its own platform), hashed identifiers (email, phone number or customer id), each hashed in the form the platform documents: Google gets a Gmail address without the dots and the part after a +; Microsoft Ads gets the email without the dots and the part from + to @, and gets the email and phone number only when the business turned enhanced conversions on; Reddit gets an email only when the part before the @ is letters and digits, and no phone number; Snapchat and Pinterest get the hashed email or phone number with their own click id, ScCid or epik; X gets its click id, twclid, and the hashed email or phone number; Campaign Manager 360 gets only the Google click id, gclid. We never collect cross-site ids such as TDID or UID2. A phone number is used only with its country code, either as written or completed with the business's chosen default phone country. Then the event time, value and currency, and, if the workspace allows it, the user-agent string (only to Meta, TikTok, OpenAI Ads, Reddit, Snapchat and Pinterest; never in strict consent mode). Before anything leaves our servers, page URLs, page titles, referrers and IP addresses are removed, the site address is cut to its domain, and in HIPAA mode event names are replaced with neutral labels (event_1). Every payload sent is recorded in the workspace's audit log. In HIPAA mode nothing is sent until the workspace has accepted a Business Associate Agreement. A workspace in HIPAA mode sends nothing at all to Snapchat, Pinterest or X, whatever its ad category. A conversion older than 7 days is never sent as a live conversion, and an order or lead marked as a test is never sent.

A workspace can also send its own records to systems it chooses: signed webhooks to an address it enters, Zapier, a read API with keys it creates, and Google Analytics 4. These carry what the workspace sees in its dashboard: outcome ids, stages, times, values and the marketing source. A workspace can also export the same records daily to its own data warehouse or bucket (Amazon S3, Google BigQuery, PostgreSQL, SQL Server; Snowflake and Redshift read the S3 files), to an Amazon SNS topic or SQS queue, or as a summary to a Google Sheet. They never carry a raw email address or phone number (we do not store them). In HIPAA mode campaign names are left out unless the workspace owner confirmed that they hold no health information, and nothing is sent to Google Analytics. Google Analytics gets an event only for a visit whose consent state is granted; turning on HIPAA mode or strict consent deletes every stored Google Analytics client id at once. When a workspace leaves the agency that managed it, the API keys and webhook endpoints that agency's staff made are revoked and turned off at once, and the webhook endpoints they pointed elsewhere and the Google Analytics destination they saved are turned off.

6. Data retention

• Event records (clicks, link conversions, bio-page views, visitor profiles, ad-click records, relayed conversions with hashed identifiers only, call records and call state, site visits and page views, the hashed email / phone links to clicks, and conversion outcomes with their history) are kept for the period the business chose for its workspace: 90 days, 12 months, 24 months or with no time limit, measured from the record's last update, and purged nightly after that. A new workspace keeps them 24 months, or 90 days in HIPAA mode, where "no time limit" cannot be chosen and 12 or 24 months need an explicit confirmation; workspaces created before this setting keep 90 days until they change it. Records with their own shorter period below keep it: the setting never makes a period longer than that.
• With each outcome and each conversion prepared for an ad platform we keep the hashed email and phone number in the forms the ad platforms match on:
  • CanonicalOutcome.matchKeys: SHA-256 hashes only, each made under one ad platform's documented rule: email (the address trimmed and lower-cased), emailGmailCanonical (a Gmail address without the dots and the +suffix of its local part), emailNoDotsNoPlus (any address without them), emailAlnumLocal (the plain hash, kept only when the part before the @ is letters and digits), phoneE164Plus and phoneDigits (the number in international form, with and without the +, completed with the workspace's default phone country when it was typed without a country code). A key that cannot be made correctly is left out; when a phone number made no key, one word says why (phoneNoKey: hashed = it arrived already hashed, raw = it had no usable country code). When an email address made no key (it was not in the form of an address, such as text around it), one word says so (emailNoKey: shape). It holds never the raw email address or phone number, and not the country. Send each ad platform the hashed email or phone in the form it matches on, when the outcome is relayed as a conversion (the outcome keeps them so a later stage can be relayed after the raw values are gone). Kept as long as the outcome: the workspace's retention setting, 90 days by default in HIPAA mode (24 months otherwise), then deleted with it. The copy inside the request sent (or approved) to an ad platform, in the record of what was sent (EgressLog, RelayBatch), is replaced by a fixed text by the daily purge job 90 days after it was written.
  • RelayConversion.matchKeys: SHA-256 hashes only, each made under one ad platform's documented rule: email (the address trimmed and lower-cased), emailGmailCanonical (a Gmail address without the dots and the +suffix of its local part), emailNoDotsNoPlus (any address without them), emailAlnumLocal (the plain hash, kept only when the part before the @ is letters and digits), phoneE164Plus and phoneDigits (the number in international form, with and without the +, completed with the workspace's default phone country when it was typed without a country code). A key that cannot be made correctly is left out; when a phone number made no key, one word says why (phoneNoKey: hashed = it arrived already hashed, raw = it had no usable country code). When an email address made no key (it was not in the form of an address, such as text around it), one word says so (emailNoKey: shape). It holds never the raw email address or phone number, and not the country. The hashed email or phone sent to each ad platform for this conversion (what the platform matches on). Kept as long as the relay row: the workspace's retention setting, 90 days by default in HIPAA mode (24 months otherwise), then deleted with it. The copy inside the request sent (or approved) to an ad platform, in the record of what was sent (EgressLog, RelayBatch), is replaced by a fixed text by the daily purge job 90 days after it was written.
• Store orders and refunds and other conversion outcomes (leads, calls, forms, CRM stages): an outcome is kept for the business's retention period after its last update from the source system (a lead still moving through a CRM is kept while it moves); its refunds go with it.
• An outcome's stored journey (OutcomeTouch), its stage history (OutcomeStageEvent) and the fields the site passed with it that the business allowed with a type (OutcomeField: a number, a listed value, a date or an id as the site sent it; short text only outside HIPAA mode; a value shaped like an email address is refused; a value the page sent is kept as a claim, never as revenue) are kept as long as the outcome record is kept, and deleted with it. This applies to every outcome that is matched to a click (a lead, a call, an order). The journey is a copy of the link clicks, the ad clicks the capture script recorded, and the site visits tied to the outcome, from the 90 days before it and, until those records are purged, also later ones. For each it keeps the time, channel, source, medium, campaign, term, content and landing path (no landing path in HIPAA mode). It holds no ad click ids, no visitor id, no IP address and no user agent, only an internal reference to the click or visit record it was copied from (for a link click or an ad click, the id its click id olidis made from). So a visit can stay in an outcome's journey after the visit record itself is purged. The stage history records when the outcome reached each stage (stage, status, time and source). A record of which import wrote or changed an outcome (DataInWrite) is kept and deleted with the outcome. It also keeps the hashed email, phone and match keys the outcome held before that write, so that undoing an import can put them back; they are deleted with the outcome. Why a payment was not sent to the ad platforms by the first-payment rule (OutcomeRelaySkip: a fixed reason, the source and the time) is kept and deleted with the outcome. What the CRM, Klaviyo or Marketo writeback did for a lead (WritebackResult: a fixed status and reason, the CRM's or tool's own id of the record it found or made, and the names of the fields it wrote, never their values) is kept and deleted with the outcome, or when you disconnect that tool.
• When you turn on writeback for a CRM, Klaviyo or Marketo, the email address and phone number of a new lead from your site are kept, encrypted, inside the background job that finds that person's record there. They are deleted when the job ends, and kept at most 24 hours. Klaviyo and Marketo jobs keep the email only. Writeback is never used in strict consent mode, for a visitor who refused consent or sent Global Privacy Control, or for a lead with no matched ad click. In HIPAA mode it stays off until you record a BAA with that vendor.
• Import records (one per CSV upload or scheduled file import: the file's name, the column numbers, the counts, the status and who started it; never a row of the file): a CSV upload's record is deleted 13 months after the import; a scheduled file's record then keeps only a fingerprint of the file and its status, so the same file is not imported again.
• Store orders and refunds recorded by the earlier Shopify order integration (the order id and number, value, currency, status, the click id and refund amounts; no email, phone or name): deleted 90 days after the order was placed or the refund recorded.
• Pixel context tokens: deleted after they expire (30 minutes).
• Pixel events from the older tracking pixel (PixelEvent): deleted 90 days after they were recorded.
• The record that a webhook, Zapier or Google Analytics send was blocked or failed (field names only, never values): deleted 90 days after it was written; the record of a send is kept. A Zapier connection that Zapier turned off is deleted 30 days later, with its delivery log, or sooner when the same key has more than 50 of them for one event.
• Background jobs (work queued for later, such as an update to a CRM; a job can hold hashed identifiers or fields a provider sent): deleted 30 days after the job finishes.
• Agency invites: an invite can be accepted for 7 days; an unaccepted invite is deleted 30 days after it expired, and an accepted invite keeps no email address after 30 days.
• Daily rollups for long-range dashboards: kept beyond 90 days.
• The audit log and the record of what was sent to ad platforms, relay batches and link version history: kept as the disclosure record, unless the workspace owner asks for earlier deletion. These hold configuration and payload records, not raw click events. In the record of what was sent to ad platforms and in relay batches, every hashed email address and phone number, click id, browser id and user agent is replaced by a fixed text 90 days after it was written; the event name, time, value, currency, the ad account and a hash of the request as sent are kept. Team members below admin see those values masked, and exporting the record needs the export permission.

AI agents (optional, off by default). If a workspace owner turns on the AI Analyst and AI Media Planner, OrcLink sends aggregate report numbers of that workspace (totals by channel, campaign, campaign group or keyword; counts and money; groups under 5 outcomes combined) to Anthropic, PBC, which acts as our sub-processor for this feature only, to write explanations and answers. No person-level record, contact detail, outcome, click or session identifier is sent, and a request that looks like it holds an email address, a phone number or a hashed identifier is not sent. In HIPAA mode the agents stay off until the workspace records a Business Associate Agreement with Anthropic. Questions and answers are kept 30 days; detected changes 90 days. Each request is recorded in the workspace audit log without its content.

Billing. Payments for OrcLink are handled by Stripe. Stripe Checkout collects your billing email and payment method and keeps them at Stripe; OrcLink stores only the Stripe customer and subscription ids. When you delete your account, OrcLink cancels the subscription and deletes the Stripe customer. If you cancel in the app, OrcLink keeps your cancellation reason and the optional text you write until the workspace is deleted.

Agencies that manage client workspaces in OrcLink keep account and configuration records only (no visitor data), kept until changed or the organization, workspace or user is deleted. When a workspace leaves an agency, every team member and invitation the agency added, the agency's API keys, endpoints, ad destinations, cost sources and share links, and the agency's client-visibility setting end at once:

• Organization: The agency's name and white-label settings (product name, colours, sender name, email and app domains and their verification state).
• OrganizationMember: Which OrcLink user is an owner, admin or staff member of the agency, and staff's default role in client workspaces.
• OrganizationWorkspaceRole: A staff member's role in one client workspace (admin, member, viewer or none).
• WorkspaceClientMember: Which OrcLink user is a read-only client user of one client workspace.
• ClientAccessPolicy: Whether client users of a workspace see person-level rows (default: aggregates only).
• OrganizationInvite: The invited email address, the kind (staff or client), the role, the workspace, and the sha256 of the invite token (never the token). The invite can be accepted for 7 days; an unaccepted invite is deleted 30 days after that, and an accepted one keeps no email after 30 days (SHORT_RETENTION_TABLES).
• OrganizationTemplate: A client workspace template: stage dictionary, channel rules, campaign groups and capture settings. No integrations, secrets, API keys or data.
• OrganizationLogo: The agency's logo image (PNG, JPEG or WebP, at most 256 KB) and its sha256.
• ShareLink: A read-only share link: label, report view, range, expiry, revocation time and the sha256 of its token (never the token).
• WorkspaceMember and Invitation (agency marks): On a team member or a pending team invitation that an agency added through its organization role: the organization's id, and on the member the id of the OrcLink user who added them. Removed with the row: every marked row ends when the workspace leaves that organization or the person who added it leaves the organization. On every team member: when they dismissed the notice of what a detach removed (a time).
• AdDestination, MetaIntegration and AdSpendSource (savedBy): The id of the OrcLink user who last saved an ad-platform destination or ad cost source. A configuration record: when that person no longer belongs to the workspace after it leaves its organization (or leaves the organization), the destination or cost source is turned off (the legacy Meta integration is deleted).

7. Your rights

Depending on your jurisdiction you may have the right to access, correct, export, or delete personal data we hold about you. Contact [email protected] and we will respond within 30 days.

Businesses that use OrcLink decide what is collected about their visitors and customers; OrcLink processes that data for them. To access, export or delete what OrcLink holds about you for a business, or to opt out of its use for advertising, ask that business: it can find your records by your email address or phone number (OrcLink stores only hashes of them) and export or delete them in one step, and it can offer a request form that records your request without telling whether any data exists. Deleting in OrcLink does not delete the record in the business's own systems (its CRM or store). Records of these requests are kept 3 years and never hold your email address or phone number.

8. Changes

We will post material changes to this policy on this page with a new effective date. Continued use of OrcLink after a change constitutes acceptance.