Sushinet

Rules2Tag — Privacy Policy

Last updated: 17 August 2026. Maintained alongside the code it describes; see §14 for how changes are announced.

Summary — the short version

Rules2Tag tags your customers, orders and products according to rules you define. To do that it reads attributes of your store's records and, for customer rules, keeps a small derived profile per customer (lifetime spend, order count, email, postcode, and similar). It exists to organise your data in your store. We never sell data, never use it for advertising, never contact your customers, and share it with no one — we currently use no third-party sub-processors at all.

Which app this policy covers

Rules2Tag (the Shopify app), built and operated by Edwin Guo (ABN 20 938 499 163), a sole trader in New South Wales, Australia, trading as Sushinet ("we", "us").

One app per policy, so nothing here describes a product you did not install:

1. What we collect, and why

1.1 Tag rules (no personal data)

Your rule definitions: conditions, tag text, state. These describe your policy, not any person.

1.2 The customer profile (personal data — the heart of this app)

For customer-target rules we maintain one derived row per customer (CustomerAggregate):

Field Source Why a rule needs it
Lifetime spend, order count, last-order date Your orders, summed by us VIP / loyalty / win-back tiers
Purchased product / collection / SKU ids Order line items "has bought X" rules
Email, email-verified, marketing-consent state customers/update webhook email-domain and consent rules
Postcode (from the default address) customers/update webhook location rules
Tax-exempt flag, Shopify tags customers/update webhook wholesale/segment rules
Last abandoned-checkout time Shopify's abandoned-checkouts API win-back rules

We deliberately do not store names or phone numbers — no rule reads them, so we do not keep them. Our Protected Customer Data declaration to Shopify lists exactly Email and Address, for the reason "store management".

1.3 Managed-tag bookkeeping

Which tag each rule applied to which record (ManagedTag), and per-order idempotency ledgers (CountedOrder, ProductCountedOrder). These reference customer and order ids; they are what makes tag removal automatic and re-processing safe.

1.4 Job queue (transient)

Webhook deliveries are processed through a job queue. A queued job briefly holds the raw webhook body — which for orders includes customer name, email and addresses. The payload is scrubbed the moment a job finishes or terminally fails, so raw webhook data survives only for the seconds-to- minutes a job is in flight. Completed jobs keep only counts (rows examined / rows changed).

1.5 What we do NOT collect

No payment card data (we never see it), no passwords, no browsing behaviour, no data from stores that have not installed the app, no customer names, no phone numbers.

2. Roles

You (the merchant) are the controller of your customers' data; we process it on your instructions — installing the app and defining rules are those instructions. Our Data Processing Agreement (Data Processing Agreement) binds us to that role.

3. Where data lives

One server (Oracle Cloud, encrypted block storage), one SQLite database per app, TLS for all transport. The same server hosts Ruleproof; the apps run as separate system users with separate databases and separate credentials.

4. Who we share data with

No one. As of this policy's date Rules2Tag has no third-party sub-processors — no analytics, no error-tracking service, no email provider touching customer data. If that changes (an error tracker is under consideration), the DPA commits us to 30 days' notice before any sub-processor can touch merchant personal data, and this section will list it.

5. How long we keep data

6. Access, and the access log

One operator. Server access is by SSH key only (password auth is disabled). Every deliberate touch of protected customer data — profile writes from customers/update, and everything the three compliance webhooks do — is recorded in an append-only access log holding counts and reasons, never ids. We state the log's honest limits: it does not capture the operator reading the database file directly over SSH.

7. Security, and if it fails

Encryption in transit (TLS everywhere) and at rest (encrypted block storage); key-only server access; separate system users per app; HMAC verification on every webhook before any processing; data minimisation as a design rule (see §1.2). Incident handling, including our commitment to notify affected merchants within 72 hours of confirming a breach of their data, is defined in our internal security policy.

8. Your customers' rights

Access, correction and erasure run through you, the controller, via Shopify's mandatory webhooks — customers/data_request (we alert the operator, who must answer within 30 days), customers/redact and shop/redact (automatic, logged). We honour these regardless of whether GDPR, the Australian Privacy Principles, or another regime applies to you.

9. Scopes and Protected Customer Data

We request the minimum scopes the features need: read_customers, write_customers, read_orders, read_products, write_products — and we have requested read_all_orders solely so "lifetime spend" can be computed from your full order history rather than 60 days. Our PCD declaration: data use store management; fields Email and Address only.

10. Changes and contact

Material changes are announced in the app and take effect no sooner than 14 days after notice. Questions, requests, complaints: support@sushinet.fyi.