How data actually flows through Signals.
Written for the person who has to approve this. What we capture, how identity is resolved, what we write back to Shopify, what we send outward, and what happens when something fails.
Five stages, in this order, every time.
Each stage is independent of the one after it. A failure late in the path never invalidates work done earlier.
-
1. Response capture
A survey or Spark answer is accepted and durably stored before anything downstream is attempted.
-
2. Identity resolution
The response is matched to a Shopify customer where a reliable signal exists — or kept anonymous where it does not.
-
3. Shopify context
Order, product, and customer context is attached so the response is interpretable later.
-
4. Customer properties
Configured answers are mapped to named customer properties and written back to Shopify.
-
5. Outbound events
Events and property updates are delivered to Klaviyo and Compass with retries and idempotency.
Response capture Identity resolution Shopify context Customer properties Klaviyo / Compass
Store first, enrich second.
The customer-facing write path does as little as possible. A response is validated, persisted, and acknowledged; identity resolution, context enrichment, and outbound delivery all happen afterwards, asynchronously.
- The write path is short: validate, persist, acknowledge. Enrichment happens after the response is safe.
- Partial progress on a multi-question survey is recorded, so an abandoned survey is still data.
- Every response carries the survey version it was answered against, so later edits do not rewrite history.
- Timestamps are recorded in UTC with the originating context preserved.
- Nothing downstream is required for a response to be captured successfully.
Matched, or honestly unmatched
Signals resolves identity from explicit signals. Where none exists, the response stays anonymous rather than being attached to a probable customer.
Session identity
A logged-in Shopify customer account is the strongest signal and is used directly.
Signed links
Sparks and surveys delivered by email carry a signed, single-purpose token that identifies the recipient without exposing customer data in the URL.
Order context
A post-purchase placement resolves identity from the order that just completed.
Explicit non-resolution
When no reliable signal exists, the response stays anonymous. Signals does not infer identity from weak signals.
Webhooks in, verified and idempotent.
Commerce context is what makes a response interpretable six months later. Signals keeps it current through Shopify webhooks rather than repeatedly re-reading your whole catalog.
- Shopify data is read through the Admin API under the scopes you approved at install.
- Webhooks keep customer and order context current rather than relying on periodic full syncs.
- Webhook deliveries are verified against the Shopify HMAC signature before being processed.
- Webhook handlers are idempotent — a redelivered event produces no duplicate state.
- Handlers acknowledge quickly and process asynchronously, so Shopify never waits on our work.
- App uninstall and customer data request webhooks are handled as part of the same path.
Inbound webhook handling
- 1 Verify HMAC signature; reject if invalid.
- 2 Check the delivery identifier against processed events.
- 3 Acknowledge to Shopify immediately.
- 4 Enqueue the work for asynchronous processing.
- 5 Apply state changes idempotently.
Answers become named, versioned attributes.
A raw answer is not directly useful to a segment builder. Signals maps configured answers onto named customer properties with stable meanings, then writes them back to Shopify.
See how profiles are built- You define which answers become properties and what those properties are called.
- Property writes are applied as the latest declared value, so a customer changing their mind updates the record.
- Writes back to Shopify use the same least-privilege scopes granted at install.
- Where supported, values can be written to customer metafields so your theme and other apps can read them.
- Property mapping is versioned, so you can see when a definition changed.
Where the data goes next
Outbound delivery is queued and asynchronous. The customer never waits on a third-party API, and a third-party API never blocks a response.
Klaviyo
Survey and Spark events are delivered as Klaviyo metrics and profile property updates, matched to the Klaviyo profile by identifier.
Compass
Responses are contributed to the shared event model and unified profile. Optional — Signals functions fully without it.
API and export
Your response data is available through the API and full export, so it is never locked in.
Designed for the day something is down.
Distributed delivery fails eventually. The question is only whether the failure costs you data or visibility. Here, it costs neither.
See the Klaviyo integration- Outbound deliveries are queued, not performed inline with the customer’s response.
- Transient failures — timeouts, 5xx, rate limits — are retried with exponential backoff and jitter.
- Every outbound event carries a stable, deterministic identifier so a retry is deduplicated by the destination rather than creating a second event.
- Retries are bounded. After the limit, the event is held and the failure is surfaced in Signals rather than discarded silently.
- A destination outage is not data loss: responses remain in Signals and delivery resumes when the connection recovers.
- Disconnecting a destination stops delivery without affecting your stored response history.
Where data lives and how long it stays
Every item below corresponds to an implemented control, not an intention.
Known processing region
Response data is processed and stored in a defined region. The current region is documented and disclosed before you install.
Encryption
Data is encrypted in transit and at rest.
Tenant isolation
Each merchant’s data is isolated. One store’s responses are never queryable from another.
Configurable retention
You set how long responses are retained. Retention is enforced by the platform, not by policy alone.
Deletion support
Customer data deletion requests are supported, including the Shopify mandatory data request webhooks.
Export on demand
Full response export is available at any time, in a format you can actually use.
The short version, for your review notes
- A response is durably stored before any downstream work is attempted.
- Identity is resolved from explicit signals only — never inferred.
- All inbound webhooks are signature-verified and handled idempotently.
- All outbound deliveries are retried, deduplicated, and bounded.
- Failures are visible in the product, not silent.
- Data is isolated per tenant, encrypted, retained on your schedule, and exportable.
Architecture questions
What happens to a response if Klaviyo or Compass is down?
Nothing is lost. Responses are durably stored in Signals before any outbound delivery is attempted. Failed deliveries are queued and retried with exponential backoff, and delivery resumes when the destination recovers.
How does Signals avoid sending duplicate events?
Every outbound event carries a stable, deterministic identifier derived from the response. If a retry occurs, the destination deduplicates against that identifier instead of recording a second event.
How are Shopify webhooks handled?
Webhook deliveries are verified against the Shopify HMAC signature, acknowledged quickly, and processed asynchronously. Handlers are idempotent, so a redelivered webhook produces no duplicate state.
Where is response data stored?
Response data is processed and stored in a defined region, encrypted in transit and at rest, and isolated per tenant. The current processing region is documented and disclosed before installation.
Can I get my data out?
Yes. Full response export and API access are available at any time, and configurable retention plus deletion support mean you control how long data is kept.
Something not covered here? Get in touch — we would rather answer a hard question than have you guess.
Evaluate it properly. Then install it.
Review our security practices and API documentation, or talk to us about your specific requirements.