Security & Privacy
Most marketing attribution tools work by sending your visitor and lead data to their servers. AttribuLead doesn’t.
AttribuLead is a WordPress plugin. It runs entirely on your own web server, and it writes attribution data into your own WordPress database. Your visitor and lead data is never transmitted to AttribuLead. We could not access it if we wanted to — there is no pipe from your site to us.
This page explains exactly what that means, what data exists where, and what we do and don’t do with it.
The short version
| Question | Answer |
|---|---|
| Does AttribuLead see my visitors’ data? | No. It stays in your WordPress database. |
| Does AttribuLead see my leads’ names or emails? | No. Never transmitted to us. |
| Is there any usage tracking or telemetry in the plugin? | No. None. |
| Does the plugin store IP addresses? | No. Not in any database table. |
| Does the plugin need an external API to work? | No. Core attribution is fully local. |
| What does the plugin send us? | Only your license key and site URL, when checking your license. |
| Do you have subprocessors who touch my lead data? | No. See our Subprocessor List. |
Where your data actually lives
When a visitor arrives at your website, AttribuLead’s tracking script records the attribution signals (source, medium, campaign, referrer, landing page) and sends them to your own site’s WordPress REST endpoint. Your server writes them to your own database.
That’s the whole loop. It never leaves your server.
AttribuLead creates its own tables inside your WordPress database:
al_visitors— visitor attribution (first touch, last touch, effective source, confidence, reason)al_sessions— per-visit attribution signalsal_conversions— form submissions with their attribution snapshotal_touchpoints— the multi-touch journeyal_assets— your campaign asset mappingsal_bot_blocks— a count of filtered bot visitsal_crm_logs— sync history, if you enable CRM syncal_revenue— revenue attribution, if you use it
You control this data completely. It lives with your hosting provider, under your backup policy, subject to your retention settings. If you delete the plugin and tick “delete all data on uninstall,” it’s gone.
What the plugin stores about visitors
The visitor identifier
AttribuLead assigns each visitor a random UUID — a string like f47ac10b-58cc-4372-a567-0e02b2c3d479. It’s generated randomly. It is not derived from an IP address, a browser fingerprint, an email, or any other personal characteristic. It’s stored in the visitor’s browser (localStorage) as a first-party value.
It is meaningless outside your own site. It cannot be used to recognise that person on any other website, and it isn’t shared with anyone.
What we deliberately do NOT store
This is worth being precise about, because it’s unusual:
- No IP addresses. There is no IP column in any AttribuLead table. The visitor’s IP is read momentarily in memory to rate-limit abusive requests (it’s immediately hashed into a short-lived key) and to nothing else. It is never written to the database.
- No user-agent strings. The browser’s user-agent is read momentarily to check it against the bot list, then discarded. It is not stored.
- No browser fingerprinting. Ever. We don’t collect canvas hashes, font lists, screen dimensions, or any other fingerprinting signal.
- No cross-site tracking. AttribuLead has no third-party cookies, no tracking pixel, no shared identity graph. A visitor’s AttribuLead UUID on your site has no relationship to their UUID on any other site.
- No third-party data enrichment. We never buy, append, or look up data about your visitors from external providers.
Attribution signals
What is stored is the attribution itself: utm_source, utm_medium, utm_campaign, ad click IDs (like gclid), the referring domain, the landing page URL, a confidence score, and a plain-English reason for the classification.
Lead data (personal data) — off by default
Lead Intelligence is the optional feature that stores the personal details a lead typed into your form. It is disabled by default. On a fresh install, AttribuLead stores no personal data whatsoever.
If you turn it on, you choose the level:
| Mode | What’s stored |
|---|---|
| Disabled (default) | Nothing personal. Attribution only. |
| Email only | Email address |
| Email + Name | Email, first/last/full name |
| Email + Name + Company | The above, plus company name and business email domain |
Three things worth knowing:
- AttribuLead only reads what the form already collected. It never asks for extra fields, and it never infers or appends data the visitor didn’t type.
- Company identification is just the email domain. If a lead submits
jane@acme.com, the company isacme.com. Free/consumer domains (gmail.com, outlook.com, yahoo.com, icloud.com, proton.me and similar) are excluded and never treated as a company. There is no de-anonymisation of unidentified visitors — AttribuLead cannot and does not tell you “Acme Corp visited your pricing page.” That’s a different (and far more invasive) category of product, and we don’t do it. - This data still never leaves your server. Enabling Lead Intelligence does not send anything to us.
Retention
- Attribution data retention defaults to 90 days, and is configurable up to 10 years or “forever.”
- Lead Intelligence data has its own separate retention, defaulting to 90 days when you first enable it (options: 30 / 90 / 180 / 365 days, or forever).
A scheduled daily task deletes data past your chosen window, oldest first.
Deletion and anonymization
Under AttribuLead → Settings, you can search for a person by email, visitor UUID, or conversion ID, and then either:
- Anonymize — strips the personal fields but keeps the attribution row, so your historical reports stay accurate; or
- Delete — removes the visitor, their sessions, and all their conversions entirely.
AttribuLead also hooks into WordPress core’s built-in personal data export and erasure tools, so subject access and erasure requests can flow through the standard WordPress privacy screens you may already use.
Consent
AttribuLead has three consent modes, so you can match it to your legal basis:
| Mode | Behaviour |
|---|---|
| Essential (default) | Always records attribution. Records source signals and a random UUID — no personal data unless you’ve enabled Lead Intelligence. |
| Consent Aware | Records attribution only after the visitor consents. Reads the al_consent cookie or a common CMP analytics-consent cookie. |
| Strict | Records nothing server-side, and the tracking script does not fire. No persistent identity is kept. |
In Strict mode, cross-session attribution is not possible — and AttribuLead tells you so in the dashboard rather than quietly under-reporting. We would rather show you an honest limitation than a misleading number.
Note: Choosing the right consent mode is a decision about your legal basis under GDPR/ePrivacy and your own risk posture. We give you the switches; we can’t give you legal advice.
The only things the plugin sends outside your server
We have audited every outbound network call in the plugin. There are exactly three, and only one of them goes to us.
1. License activation — goes to AttribuLead
When you activate or check your license, your site sends to attribulead.com:
- your license key
- the product ID
- your site URL (
home_url())
That’s the entire payload. It contains no visitor data, no lead data, and no analytics. It happens when you activate, deactivate, or when your license is periodically re-checked.
2. CRM sync — goes to YOUR CRM, if you enable it
If you connect a CRM (HubSpot, Microsoft Dynamics, Pipedrive, Salesforce, Brevo, or a generic webhook), AttribuLead sends attribution — and, if Lead Intelligence is on, the lead’s details — directly from your server to your CRM account.
This traffic goes to your CRM, using your credentials. It does not pass through AttribuLead’s infrastructure. We are not a party to it and never see it. The CRM you choose is your own vendor relationship, governed by your agreement with them.
This is entirely optional and off until you configure it.
3. The “health check” — goes to your own site
The Attribution Health screen performs a check on your site’s own REST endpoint to confirm it’s reachable. This is a loopback request from your server to itself. It is not an external call, and no data goes anywhere.
And nothing else
There is no telemetry, no usage analytics, no “anonymous statistics,” no Freemius or similar SDK, and no phone-home. We don’t know how many leads you have, which features you use, or how your site is performing — because the plugin never tells us.
Security of the plugin itself
Access control. All AttribuLead admin screens require the WordPress manage_options capability (typically Administrator). Data-modifying actions are protected with WordPress nonces to prevent cross-site request forgery.
Input handling. All database queries use prepared statements. Input is sanitized on the way in and escaped on the way out, per WordPress coding standards.
Rate limiting. The public tracking endpoint is rate-limited to resist abuse and flooding. The rate-limit key is a hash of the requester’s IP held in a short-lived transient — never persisted.
Bot filtering. Known crawlers, SEO tools, monitoring services, headless browsers, and HTTP libraries are identified and excluded, so they don’t pollute your data.
Duplicate protection. The same submission cannot be recorded twice.
Least data. The plugin is built so the sensitive fields simply don’t exist unless you switch them on.
Credential security
If you use the optional CRM sync, the credentials you enter (such as an API key, client secret, or access token) are encrypted at rest using authenticated AES-256-GCM encryption. The encryption key is derived (via HKDF) from a dedicated encryption key you can define, or from your WordPress security salts. Encryption fails closed: if the key material is unavailable, the plugin refuses to store or read the secret rather than falling back to plaintext.
In practice, a stolen database dump, an exposed backup, or read access to the wp_options table does not reveal usable CRM credentials.
Two honest boundaries:
- Encryption at rest protects against database-level exposure. It cannot protect against a full server compromise where the attacker also obtains the key material (your salts or key constant). Keep WordPress, PHP, and your host patched and access-controlled.
- We still recommend a scoped, least-privilege credential for each CRM connection (for example, a HubSpot private app limited to the scopes it needs), so that even in a worst case the blast radius is small. Rotate it if you suspect your site is compromised.
Responsible disclosure
If you believe you’ve found a security vulnerability in AttribuLead, please report it to [security@attribulead.com] rather than disclosing it publicly.
Please include steps to reproduce, the plugin version, and the potential impact. We’ll acknowledge your report within [X business days], keep you updated as we investigate, and credit you when the fix ships if you’d like us to.
We ask that you give us reasonable time to release a fix before any public disclosure, and that you don’t access or modify other people’s data while testing.
Questions
If you have a security or privacy question this page doesn’t answer — including a security questionnaire from your procurement team — contact [privacy@attribulead.com]. We’re a small team and we answer these ourselves.
Related: Privacy Policy · Subprocessor List · Data Processing Agreement · Terms of Service