Privacy Policy

Sygna helps WooCommerce merchants track and optimize their conversion signals. This policy explains what data we collect, how we use it, and your rights. We have written it in plain language. Questions? Email us at [email protected].

Sygna is currently an early-access pilot operated from Israel, built to serve merchants and their customers worldwide — including users in the European Union, United Kingdom, Israel, and beyond. We apply the same data protection standards to everyone, regardless of where they are located. As Sygna moves out of pilot, we will update this page with our registered legal entity and address.

Who this policy covers

Merchants (our customers) — site owners who connect their WooCommerce store to Sygna. This policy governs our handling of your account data.

Site visitors (end-customers of merchants)— site visitors on stores that use Sygna. The merchant is the data controller for your personal information; Sygna acts as a data processor on the merchant's behalf. We do not use your data for our own advertising or profiling.

Our role, purpose by purpose

"Sygna is a processor" is not true of everything Sygna does, and saying it as a blanket statement would misdescribe several activities. The allocation depends on who decides the purpose:

• Receiving your store's events and routing them to the platforms you selected — you decide the business purpose and the destinations; Sygna performs the service on your instructions. You are the controller (in Israeli terms, the database owner/holder responsibilities are yours) and Sygna is the processor. You are responsible for your own visitor notices.
• Delivery to a platform you connected — you select the destination and the use; Sygna executes it. Once the platform receives the data it acts under its own terms and for its own purposes, which Sygna neither controls nor can restrict on your behalf.
• Your account, authentication and service administration — Sygna decides what is necessary to operate the service. Sygna is the controller.
• Security, fraud and abuse prevention — Sygna decides the protective purpose and the retention. Sygna is the controller.
• Reliability monitoring and support diagnostics — mixed. Sygna is the controller for keeping the service working; the diagnostics themselves are minimised and exclude message bodies, tokens and raw identifiers.
• Product analytics and improvement — Sygna decides the purpose. Sygna is the controller and the data is minimised to what the improvement needs.
• Recommendations and automated analysis — where active, Sygna decides how the analysis works and you decide whether to act on it. Capabilities that are built but not switched on are not described here as things we do.
• The availability waitlist — Sygna decides the purpose (telling you once when Sygna reaches your market). Sygna is the controller, and the section below describes it in full.

Data we collect

Merchant account data

• Name, email address, business name, and site URL.
• Business profile (industry, sales channels, ad platforms, revenue range).
• Ad platform credentials — Meta Pixel ID and access token, GA4 Measurement ID and API secret, Google Ads customer/conversion-action IDs and OAuth tokens, TikTok pixel and access token. Stored AES-256-GCM encrypted. Never returned in plain text after saving.
• Notification email addresses for health alerts.
• Support messages.
• Free-text business-profile notes, if you choose to add them — see "AI processing" below for how these are handled.
• Product journey records such as pages viewed, important actions, safe summaries of inputs and outputs, request status, and test-scenario identifiers. We do not record mouse movement, screen video, passwords, access tokens, or arbitrary form fields. Exact assistant prompts and answers are retained only while an internal scenario run is explicitly active; normal customer usage stores lengths and outcome metadata only.

Conversion event data (from your site)

Sygna Connect for WooCommerce forwards normalized events to our API. Each event may include:

• Event type (purchase, add to cart, WhatsApp click, form submit, etc.).
• SHA-256 hashed email, phone, first name, and last name when available and consent permits. Hashing is one-way, but a platform that already knows a possible value can hash it and compare the result; we therefore still treat these hashes as personal data.
• Order value, currency, and product identifiers. No card numbers or payment data.
• UTM parameters and ad click IDs (fbclid, gclid, ttclid) from the URL.
• Browser-generated session ID and event ID for deduplication.
• Consent state set by your site's cookie solution.
• IP address for geolocation context.

We do not collect raw (unhashed) email addresses, phone numbers, payment card data, passwords, or special category data.

How we use this data

We do notsell your data. We do not use your customers' data for cross-site advertising or to build profiles for our own marketing.

Third-party services we send data to

• Meta (Facebook) CAPI— if you connect your Pixel, we forward events to Meta's Conversions API on your behalf. Meta's own privacy policy governs their use of that data.
• Google Analytics 4— if you connect your GA4 property, we forward events via the Measurement Protocol. Google's privacy policy applies.
• Google Ads— if you connect a Google Ads account, we forward offline conversions via Google's conversion import APIs. Google's privacy policy applies.
• TikTok— if you connect a TikTok Pixel, we forward events to TikTok's Events API. TikTok's own privacy policy governs their use of that data.
• Hosted AI / large-language-model providers — hosted AI processing is disabled for the initial beta, so no hosted AI provider currently receives pilot customer data. If enabled later, the active provider will be listed on our sub-processor page before use. Depending on the feature, the context sent may include your business-profile notes, account/site configuration, alert diagnostics, or strategy context. Sygna does not intentionally include customer-event contact fields, payment data, or hashed customer identifiers in AI context. We also remove recognizable email, phone, credential, and opaque-identifier patterns at the final provider boundary. Pattern matching cannot identify every possible name, address, or personal detail, so do not place customer personal data in profile notes or assistant questions. We will enable hosted AI only after verifying that the production account and plan are covered by processor terms that exclude prompts and responses from model training or product improvement, and will give notice before any incompatible change. Exact prompts sent for a given feature are retained only while an internal scenario run is explicitly active; normal usage retains outcome metadata only, per the retention table below.
• Cloud infrastructure — the application runs on a Hetzner Cloud server, uses Supabase for the production PostgreSQL database, and is reached through Cloudflare for DNS, TLS, and secure tunnelling. Sentry receives scrubbed application-error telemetry. The current providers and purposes are listed on our sub-processor page.
• Resend — used for every transactional email we send: health alert notifications, sign-in links, lead notifications, and the two availability-waitlist messages. Only the recipient address and the email content are shared.

We share data with the platforms you explicitly connectas destinations, and with service providers that process data on Sygna's behalf. See our Sub-processors page for the current, up-to-date lists — we will update it whenever a service provider or supported destination is added, removed, or materially changed.

How email is queued

Every message we send is queued before it is handed to our email provider, so a temporary failure is retried rather than lost. A queued message holds the recipient address inside an encrypted payload and identifies the recipient by a keyed one-way value — the address itself is not stored in readable form anywhere in the queue. Once a message has been delivered, or has given up, the stored copy of the address and the message body are erased.

Consent and suppression

Sygna Connect for WooCommerce reads the consent state from your site's cookie solution. What happens next depends on the consent posture you choose in Settings:

• Require granted consent (default) — an event is only forwarded to ad platforms when the visitor has explicitly granted analytics/ad consent. Denied or not-yet-specified consent is suppressed and not forwarded.
• Merchant-managed privacy— an optional setting an account owner may turn on for an eligible store. Under it, Sygna may rely on your versioned attestation for the uses you selected, and only when every one of these holds for that event: Sygna has no authoritative permission signal from the visitor; no consent layer was detected on your store that should be producing that decision; the visitor has not refused; your store is still eligible (you declared the business operates from Israel, and your WooCommerce base country is reported as Israel over the authenticated plugin connection and is current); Sygna observed the visitor's network location for that session as Israel; and the destination platform's own requirements permit the send. Any one of those failing returns the event to the default behaviour.
  It is a merchant responsibility, not a Sygna assessment. Sygna does not read your privacy policy and has not certified your compliance. A previous version of this page said the setting required a fresh scan proving no consent layer exists; that is not what the service does, and it never could — a scan cannot see a consent tool injected after the page loads, so its silence was never evidence of absence. What still blocks is positive evidence: a consent layer Sygna has actually observed.

Denied consent is always respected and never forwarded, in both modes. You are responsible for implementing a compliant consent mechanism on your site and for choosing the posture that matches your legal basis.

Country information, and what each piece is for

Sygna asks "which country?" three times, about three different subjects. They are separate and none of them is used as a substitute for another. None is proof of nationality, residence, incorporation or governing law, and none is derived from your currency, timezone, language or domain name.

• The network location of a signup request.When someone tries to create a new self-service account, we read the coarse country our network provider (Cloudflare) reports for that request. It decides one thing: whether self-service signup is available right now. It is not stored against your account as a fact about you, and it never applies to signing in, to your store's events, or to anything else.
• Your declared business country. The country an account owner states the store or business operates from, recorded with the wording and date of the statement. It is a representation you make. We collect no registration certificate and do not verify it.
• Your WooCommerce base country. The Store Address country configured in your own WooCommerce settings, reported by the Sygna plugin over the authenticated connection at pairing and on its regular status check, with the time and plugin version. It is used only to decide whether your store may be offered merchant-managed privacy. If it changes, or stops being reported, eligibility is withdrawn automatically.

Separately, for a visitor sessionon your store, we record a coarse classification of the network location — Israel, a territory with specific platform consent requirements, or unknown — bound to that session rather than to the visitor. It exists because some advertising platforms' requirements are territorial and cannot be applied without it. It is not a country code stored against a person, and it is not evidence about your business.

Availability waitlist

If self-service signup is not available in your market, you can ask to be told when it is. That request authorises exactly two emails and nothing else: one asking you to confirm the request, and — only if you confirm — one message when Sygna becomes available in your market. It is not a newsletter and we do not send promotions from it. A future marketing list would need its own, separate permission.

• What we store — your email address, encrypted; a keyed one-way value derived from it, used to recognise repeat requests and to honour an opt-out; a coarse market code (or none, if we could not determine one and you did not choose one); the wording version you were shown; and the lifecycle timestamps. We do not store your IP address. We do record a keyed one-way value derived from it in our security log, to detect abuse of the form; it cannot be turned back into your IP address, it is not attached to your waitlist entry, and it is deleted with the rest of that log.
• Confirmation — nothing is sent to an address that has not confirmed, beyond the single request to confirm. The link works once and expires after 72 hours. That first email also carries a link to delete the request outright, so you do not have to wait for it to expire — including if somebody else entered your address.
• Opting out — every email carries a link that works without signing in, and it is the same link in each of them, so an older message keeps working. Using it deletes the stored address immediately — from the waitlist entry and from any queued or already-sent message in our mail queue — and cancels anything still waiting to be sent. Only the keyed one-way value is kept, so a later request cannot put you back on the list by accident.
• How long — an unconfirmed request is deleted after 30 days. A confirmed entry is kept until the notification is sent, or for at most 24 months. After the notification, the address is deleted within 30 days. An opt-out record is kept for up to 24 months so the opt-out keeps working, then removed.
• Your rights — the waitlist is covered by the rights section below and by our Data Deletion policy.

Data retention

• Conversion event data — retained for up to 12 months, then deleted automatically.
• Lead records — retained until you remove the site or close your account.
• Business profile and strategy — retained until you remove the site or close your account.
• Encrypted credentials — retained until you disconnect the destination or remove the site or delete your account.
• Audit and delivery history — retained for up to 12 months.
• Store-country and business-country records — the authenticated WooCommerce base-country observations and your declared business country are kept for as long as the site and account exist, because they explain why a past event was or was not eligible. Store observations are deleted with the site; the account declaration is deleted with the account.
• Terms and Privacy acceptance records — kept for the life of the account. Each record names the exact document version and content it referred to.
• Availability waitlist — see the periods in the waitlist section above.
• Aggregated, anonymized data — may be retained indefinitely. Cannot identify you or your customers.

International data transfers

Sygna is operated from Israel. The European Commission has recognized Israel as providing an adequate level of data protection for relevant transfers from the European Economic Area, and the United Kingdom separately recognizes Israel as adequate for relevant UK transfers. Where an additional safeguard is required for processing by a service provider, we rely on the applicable data-processing terms and transfer mechanism for that service. Some providers incorporate those terms automatically; others require account-level acceptance, which must be completed before that provider is used for pilot personal data. Transfers to an advertising destination you connect are governed by your agreement with that destination. See our Sub-processors page.

Security

Ad platform credentials are encrypted at rest (AES-256-GCM). All data in transit uses HTTPS/TLS. Our logging infrastructure is configured to redact sensitive fields (tokens, API secrets, passwords) automatically. Sygna team members access customer data only when necessary for support or operations.

Cookies

The Sygna dashboard uses only essential session cookies. The WooCommerce plugin may set session-scoped identifiers on your site front-end for deduplication and attribution — you are responsible for disclosing this in your site's cookie policy and obtaining consent where required.

Your rights

Depending on where you are located, you have the right to access, correct, delete, and port your data, object to certain processing, and withdraw consent where it applies. See our Data Deletion page for how to submit requests. We respond within 30 days.

• EU / EEA and UK users — you have rights under the GDPR and UK GDPR, including the right to lodge a complaint with your local supervisory authority.
• California residents — you have rights under the CCPA/CPRA, including the right to know, delete, correct, and opt-out of certain sharing. We do not sell personal information. To exercise your rights, email [email protected].
• Israeli users— you have rights under Israel's Privacy Protection Law and Amendment 13 (effective August 2025), including the right to file a complaint with the Privacy Protection Authority (Reshut HaGana al HaPratiut).

Your responsibilities as a merchant

You are the data controller for your customers' data. You are responsible for having a lawful basis to collect and forward their data to ad platforms, disclosing your use of server-side conversion tracking in your site's privacy policy, and obtaining any required consent. We cannot take on legal responsibility for your site's own data practices.

A practical checklist, not legal approval.The list below is what merchants most often need to add to their own privacy disclosures once they connect Sygna. It is a starting template written from what the product actually does — it is not advice, not a review of your notices, and not a statement that following it makes you compliant. Whether it is sufficient for your business is your determination, and you may need a lawyer's.

• Name Sygna as a service provider that receives conversion data from your store on your behalf.
• Say what is collected. The event categories you actually send (for example page views, add-to-cart, checkout, purchase, form submissions) and the identifier categories that travel with them — hashed email and phone, advertising click identifiers, a first-party visitor and session identifier, order value and currency.
• Name the destinations you selected. Meta, Google Analytics 4, Google Ads, TikTok, or your own webhook — only the ones you actually connected.
• State the purposes: measuring which marketing produces results, and improving how the platforms deliver your advertising.
• Be honest about the platforms. Once a platform receives the data it acts under its own terms and may use it for its own purposes, including relevance and personalisation. Neither you nor Sygna controls that from here.
• Explain visitor choice. What happens when someone refuses — the data is not forwarded — and how they can refuse or change their mind.
• Mention international transfer where it applies to your customers, and the safeguards involved.
• Give a contact route for access, correction and deletion requests, and say how a request reaches you.

Children

Sygna is a business tool for adults. We do not knowingly collect data from anyone under 16. Contact [email protected] if you believe we have done so and we will delete it promptly.

Changes

We will update this page when our practices change and update the "Last updated" date above. For material changes we will notify active accounts by email.

Contact

[email protected]