Privacy and LGPD
Which data the system processes, how it is stored, for how long, and which technical measures apply.
This page describes the platform’s technical behavior: what data is read, what is stored, in what form and for how long. It is input for an LGPD (Brazilian General Data Protection Law) compliance assessment — it is not legal advice and it does not determine the legal basis, the need for consent, or the advertiser’s obligations as a controller. Each advertiser must assess its own context with its own legal counsel.
Data processed#
Stored in the visitor’s browser#
| Item | Contents | Lifetime |
|---|---|---|
| Identification cookies | Click, session and device identifiers received in the URL | Campaign window: default 30 days, maximum 365 |
| Technical domain probe | Fixed value, no personal content | 10 seconds |
| Conversion-sent marker | A flag that the conversion has already been recorded | No automatic expiry |
| Duplicate-record guard | Timestamp of the last record on the page | End of the browser session |
Details on each cookie in cookies written.
Stored on the server#
Per visit or conversion event. The full table, with the nature of each field, is in Architecture and security. In short: click and transaction identifiers, conversion value, traffic source, referrer, user agent, IP address hash, and campaign parameters filtered through an allowlist.
Name, email, phone number, CPF (Brazilian tax ID), address, payment data, cart contents and IP addresses in readable form. The platform never receives this data from the advertiser and has no way of obtaining it.
Technical measures applied#
IP hashed, never in the clear
The address is converted to a SHA-256 hash with a site-specific salt before anything is written. The original is never persisted and cannot be recovered from the hash.
Parameter allowlist
Only campaign parameters and a closed list of ad platform identifiers are kept. Anything else is dropped on input — personal data accidentally placed in the URL is never stored.
Field minimization
Every field has a size limit enforced on input, and only what attribution needs is collected.
Limited retention with automatic removal
A daily job removes events past the retention window, with no manual step involved.
First-party cookies
No third-party cookies. SameSite=Lax and Secure over
HTTPS.
Conditional geolocation
Only runs on campaigns with a city rule, and first against a local database on the platform’s own server. Campaigns with no geographic rule never use the IP for this purpose.
Retention#
| Data | Retention | Removal |
|---|---|---|
| Visit and conversion events | 30 days | Automatic daily job |
| Browser cookies | Campaign window: default 30 days, maximum 365 | Browser expiry |
| Geolocation cache | 24 h on a hit, 10 min on a failure | Automatic expiry |
| Technical markers in the browser | Session, or until the user clears them | Browser data clearing |
| Campaign configuration | For as long as the campaign exists | Deletion by the operator |
After 30 days the events are no longer queryable in the dashboard. To preserve aggregate history, export the CSV periodically — the export carries no click or transaction identifiers, only aggregates.
Sharing with third parties#
Depending on the campaign configuration, the conversion may be forwarded to the media platforms contracted for that placement, for optimization and payment reconciliation. What is transmitted in that forward: the click identifier, the transaction identifier and the conversion value.
No data that directly identifies the visitor is transmitted, because the platform does not hold any.
The list of platforms involved in each campaign, with the location of processing and the corresponding data processing agreements, is provided to the contracting party under the contract — including for building the advertiser’s record of processing activities. See Architecture and security.
Geolocation#
Only on campaigns with a city rule. Resolution happens first against a local database on the platform’s server, with no external transmission. If the local database cannot resolve and a fallback service is configured, the IP address is sent to that provider to obtain the city — which may constitute an international data transfer.
If using an external geolocation service is restricted in your context, flag it to the Moclick team: campaigns can run in “all cities” mode, where geolocation is never executed.
Data subject rights#
The platform stores no data that directly identifies a person, which means locating records depends on the technical identifiers:
| Request | How it is handled |
|---|---|
| Confirmation and access | Requires the click or transaction identifier. Without one of them there is no way to locate the record. |
| Deletion | Same condition. Request through the support channel, providing the identifier. |
| Objection to tracking | Clear the site’s cookies, or use the site’s own consent mechanism where available. |
| Portability | The data consists of technical attribution records. Export available through support, where applicable. |
Since the advertiser is the one with the relationship to the data subject, requests usually reach it first. The advertiser should forward them along with the identifier matching the order, so we can locate the records.
Responsibilities#
- Advertiser
- Disclose the cookies and tracking in use in its privacy policy; define the legal basis for processing; obtain consent where its context requires it; gate tag loading on consent management, if any; handle data subject requests arriving through its own channels.
- Moclick
- Operate the platform as described on this page and in Architecture and security; apply the technical measures listed here; honor the retention window; provide the contracting party with the list of sub-processors and the corresponding agreements; support the advertiser in handling requests that depend on platform records.
Contact#
Requests relating to personal data, deletion of records, documentation for a vendor assessment or questions about this document should be sent through the Moclick support channel, including the click or transaction identifier whenever the request involves specific records.
This document tracks the platform version and is revised whenever data handling behavior changes. See the changelog.