Rules2Tag — Privacy Policy
Last updated: 16 September 2026. Maintained alongside the code it describes; see §10 for how changes are announced.
16 September 2026 — added §1.5, which lists every order attribute a rule is evaluated against, and corrected §1.6: it claimed we collect "no browsing behaviour" while the app reads the referring website for the traffic-source rules. Nothing about what the app does changed; the policy now describes it accurately.
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:
- Ruleproof (checkout rules) — privacy policy · DPA.
- Undo History (product change history) — privacy policy · DPA. The two apps share infrastructure but hold separate databases and separate data.
- This website, and our dealings as a studio (analytics, email, LinkedIn) — website privacy policy. Separate because the roles differ: there we are the controller in our own right; here you are the controller and we are your processor.
- Rules2Tag's own processor terms — DPA.
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 Order attributes we read to evaluate a rule
Order-target rules are evaluated against the order as it arrives. These attributes are read from the webhook (or, when we re-check an existing order, from Shopify's Admin API) and compared with your rule. Most are then discarded: what survives the evaluation is the record of which tag was applied (§1.3), plus — for the customers a rule has touched — the derived profile fields listed in §1.2.
⚠️ So "read" and "kept" are different questions, and the third column answers it per attribute. The customer profile in §1.2 is built by folding orders together, so a handful of these attributes do persist in derived form: purchased product and SKU ids, discount codes ever used, the last-seen locale, and the order count and lifetime spend the totals add up to. Everything else is used and dropped.
| Attribute | Why a rule needs it | Kept? |
|---|---|---|
| Total, currency, tip, weight, item count | Value and size rules ("over $500", "heavy order") | Only as a running total and order count on the profile (§1.2) |
| Line items: quantity, SKU, vendor, title, product id | "Contains product X" rules | Product, collection and SKU ids persist on the profile (§1.2); quantity, vendor and title do not |
| Shipping and billing country and company | Country rules, and business-vs-consumer rules | No |
| Shipping method chosen (the rate name) | "Express order" / delivery-speed rules | No |
| Discount codes, payment gateway names | Campaign and payment-method rules | Discount codes persist on the profile (§1.2); gateway names do not |
| Financial and fulfilment status, cancelled-at, cancel reason | Refund, unfulfilled and cancelled-order rules | No |
| Created-at, order name, order id, app id, source, location | Date rules, POS/draft-order rules, bookkeeping | The last-counted order id and date only (§1.2) |
| Customer locale, customer id and tags | Language rules, and rules that combine order and customer | Locale and tags persist on the profile (§1.2) |
| The customer's order note | The "orders with a note" rule (gift messages, delivery instructions) | No — never stored |
| The referring website | The traffic-source rules, including "arrived directly" | No — never stored |
Two of these deserve naming rather than burying in a list:
- The order note is free text your customer typed, so it can contain anything they chose to put there. We read it only to answer "is there a note at all?" and to match a pattern you wrote; we do not store it, log it, or read it for any purpose of our own.
- The referring website is the URL your customer came from before they bought
(Shopify's
referring_site, andcustomerJourneySummary.firstVisit.referrerUrlwhen we re-check an order through the API). It exists here for one reason: the rules that tag an order by where it came from, including the common case of tagging orders that arrived with no referrer at all. It is a single URL attached to one order — not a browsing history, not a session, not a trail across pages, and we neither store it nor build any profile from it.
1.6 What we do NOT collect
No payment card data (we never see it), no passwords, no data from stores that have not installed the app, no customer names, no phone numbers, no street addresses, no cookies or tracking pixels on your storefront.
On browsing behaviour — this section said "no browsing behaviour" until 16 September 2026, which was not accurate, and the correction matters more than the wording: we read one field that describes how a customer arrived (the referring website, §1.5), because rules tag orders by traffic source. We do not track customers across pages or sessions, do not place anything on your storefront, and do not retain the field. Saying "none" was simpler than the truth, so it is now stated as what it is.
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
- Customer profiles, managed tags, ledgers: for the life of your installation. These ARE the product — deleting a profile would silently break the rules that read it — so their retention period is "while you use the app", which is a defined period, not an indefinite one:
- On uninstall: Shopify sends
shop/redact48 hours later and we erase everything — every table, every row, the OAuth session included. - On a customer erasure request:
customers/redacterases that customer's profile, ledgers, managed-tag rows and any still-queued jobs naming them, immediately and permanently. - In-flight job payloads: scrubbed at completion (see §1.4).
- The access log: counts and reasons only — it contains no personal data to retain.
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; protected fields — Shopify's four named
categories — Email and Address only, never Name or Phone.
Reading orders at all means we handle protected customer data beyond those four named fields, and §1.5 now lists every order attribute a rule can be evaluated against, including the customer's order note and the referring website, and says for each whether it is kept. Neither the note nor the referring website is ever stored.
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.