Trust center
Where data lives, who the sub-processors are, what flows where. Built for legal teams that need to clear Beaconry before purchase.
Data flow at a glance
Beaconry has no central server that receives event data. Every event flows from your visitor's browser to your own WordPress install, then directly to the platform APIs you configured. The diagram below is the full picture.
Three tiers, five outbound paths. Visitor's browser, your WordPress install, the configured platforms. Beaconry's central worker is only on the license-validation and Google-Ads-OAuth path, not on the event path.
Tier 1, browser
Captures consent state (nl_pref) and click-IDs (nl_ext), POSTs events to your domain via navigator.sendBeacon. Same-origin, no third-party domain.
Tier 2, your WordPress
Validates consent, normalises event-type, hashes PII with SHA-256, stores encrypted credentials in your database, dispatches to platforms server-to-server.
Tier 3, platforms
Meta, TikTok, Google Ads, LinkedIn, GA4 receive the events you configured. Each platform's own data-processing agreement applies from here.
Sub-processors
Beaconry only uses the sub-processors strictly required to deliver the product. Your visitor's PII never reaches any of them.
| Sub-processor | Purpose | Data category | Region | DPA |
|---|---|---|---|---|
| Cloudflare | License validator + Google Ads OAuth broker (Workers + KV). | License key, site URL. No event data. | Global edge, EU-eligible. | Cloudflare DPA |
| Polar | Checkout, license issuing, VAT collection (Merchant of Record). | Buyer billing details (you, the customer). Not your visitors. | EU. | Polar DPA |
| GitHub | Plugin source-code hosting + release artifacts. | Source code, no customer data. | US. | GitHub DPA |
Not a sub-processor: Meta, TikTok, Google Ads, LinkedIn, Google Analytics. You configure them directly in your WordPress install with credentials you own. They are your data-processors via your own contracts with each platform, not via Beaconry.
What never leaves your infrastructure
- Raw email addresses, phone numbers or other PII (always SHA-256 hashed before transmission).
- Your platform access tokens (encrypted at rest with AES-256-GCM using your WordPress auth salts).
- Your visitors' IP addresses (sent to the platforms only, not to Beaconry's central worker).
- Full event payloads (sent to the configured platforms' official APIs only).
- Refresh tokens (encrypted at rest in your WordPress database).
What Beaconry's central worker sees
- Your license key (one record per active install).
- Your site URL (so we can validate the seat-count against your tier).
- For Google Ads only: the OAuth handshake transit (we proxy the upload, but body is encrypted in transit and not stored).
That's it. No event data, no visitor info, no platform API responses, no analytics about your store or your campaigns.
Compliance posture
- GDPR-aligned consent gate (
nl-data-gate) shipped with the plugin. - SHA-256 hashing on PII before any transmission, per each platform's matching guidelines.
- Encrypted credentials at rest. Optional
wp-config.phpconstants to keep them out of the database entirely. - No tracking beacons or analytics on this marketing site (Beaconry dogfoods its own privacy stance, only an error-beacon for ops signals).
- Server access logs kept 14 days max, security purposes only.
- Vendor: MALUR — IT Consulting & Services Ltd, Cyprus.
Reporting a security issue
Email security@beaconry.app. We acknowledge within one working day and aim for a fix or mitigation within 30 days for medium-severity issues, 7 days for high-severity. Coordinated disclosure preferred.