This document describes how the email open tracking system available in the magnews platform works. It provides information about the data collected through the tracking system, the purposes for which such data may be used, data retention methods, the security measures adopted, and the options available for managing tracking.
1. Identifier / technical name of the tracking pixel
The tracking pixel is implemented through a remote image resource, technically identifiable as wb.gif, embedded in email messages to enable the detection of message opens when tracking is enabled.
2. What information does the pixel collect?
The pixel allows the registration of an open event associated with the sent message and the recipient. The event may include technical identifiers of the message and contact, open timestamp, IP address, user-agent/mail client, information about the device or platform, geographic data derived from the IP address, and any technical information useful for distinguishing human interactions from opens generated by automated systems or bots.
Specifically, upon request of the wb.gif resource, the platform generates an email open event, technically classified as a WEBBUG event.
The collected data may include:
| Category | Collected data |
|---|---|
| Event identification | Message/newsletter ID, contact/reader ID, event timestamp |
| Technical data | Client IP address, user-agent / mail client, platform or device |
| Derived data | Geographic area derived from the IP address, possible bot/human classification |
| Context data | Channel, objective/possible goal, technical information related to the delivery |
3. How long and where is the collected information stored?
Tracking data is stored within the platform’s statistical archives and event repositories. It is available in detailed form within contact statistics and in aggregated form within newsletter, journey, or communication statistics.
The retention period depends on the account configuration, in particular on the CSS / retention settings applicable to the customer environment.
The stored tracking data includes:
| Level | Storage method |
|---|---|
| Contact statistics | In detailed form, associated with the individual contact |
| Newsletter / journey statistics | In aggregated form |
| Application database | Within the platform’s statistical/event archives |
4. What are the purposes of the pixel?
The pixel is used to detect email message opens and generate statistics on recipient interaction with sent communications. Depending on the customer's configuration, this information may be used both for aggregated performance statistics and for analyses or automations related to individual contacts.
The technical and functional purposes of the pixel are:
- detecting email message opens;
- producing communication performance statistics;
- measuring the open rate at an aggregated level;
- feeding contact, newsletter, journey, or automation statistics;
- supporting reporting logic and, if configured by the customer, segmentation or automation based on interaction;
- supporting deliverability analysis.
5. Is the pixel used for global statistics? Is it unique? Are the data anonymized? Are personalized measurements performed?
The pixel is technically unique, allowing the association of the open event with the message and the recipient. The related technical data, including IP address and user-agent, are not anonymized through dedicated application options. The platform may apply technical exclusions for specific IP addresses, user-agents, or hosts, for example to reduce tracking of bots or scanners, but such exclusions do not constitute an anonymization mechanism.
Since the event can be associated with an individual contact, the measurement is not exclusively aggregated, except in the case of specific configurations or subsequent statistical aggregations.
Summary
| Question | Answer |
|---|---|
| Is the pixel unique? | Yes, the pixel query string is unique in order to associate the open event with the message/recipient. |
| Are the technical data anonymized? | No, they are not anonymized. |
| Is the IP address masked? | No, the IP address is stored in clear text. |
| Are there options to anonymize IP addresses / user-agents? | No, there are currently no application-level masking or anonymization options available. |
| Are personalized measurements performed? | Yes, if tracking is associated with the contact and is available in contact statistics. |
NOTE: Technical system blocklists exist to exclude specific IP addresses, user-agents, or hosts associated with bots/scanners from tracking, but these do not anonymize the data; they may simply prevent certain events from being recorded.
6. Is a mechanism implemented for the granular withdrawal of consent to tracking through the pixel?
The platform provides a contact-level notrack flag, which allows the exclusion of an individual recipient from tracking for all communications sent to that recipient. This flag has a global effect on tracking, meaning it disables both open tracking through the pixel and link tracking, which is performed through the URL rewrite technique.
Current status
| Level | Available action | Granularity |
|---|---|---|
| Individual contact | notrack flag | disables open and link tracking together for all communications sent to the contact |
| Single newsletter/delivery | disable open detection | applies to the entire delivery, not to an individual contact |
| Account/CSS | disable webbug and link tracking separately | separate configuration possible at account level |
7. Have measures been implemented to minimize and secure the data collected through the pixel?
The platform adopts technical measures aimed at limiting the intelligibility and manipulability of the identifiers used in the pixel. The pixel contains technical identifiers and a hash linked to a contact secret, making the reference not directly intelligible or manipulable without access to the application systems and the platform database. The data is stored in pseudonymized form, and the correspondence between technical identifiers and the contact is maintained within the application/database layer.
Upon permanent deletion of the contact, the data becomes completely anonymized, as the information required to “reconstruct” to whom those events belonged is no longer available.
However, it should be noted that the technical data collected at the time of the open event, such as IP address and user-agent, are not anonymized through dedicated application-level masking mechanisms.
Implemented measures
| Measure | Status |
|---|---|
| Identifier not directly intelligible without access to the database | Yes |
| Unique query string | Yes |
| Presence of a hash linked to a contact secret | Yes |
| Webbug manipulability | No, protected by hash-secret logic |
| Logical separation between technical identifiers and personal data | Yes, through the application/database layer |
| Anonymization after contact deletion | Yes, the remaining technical data can no longer be directly associated with the deleted contact |
| IP/user-agent anonymization | No, except in the contact deletion scenario described above |
8. Does the platform record the data subject’s choices?
The platform is able to record and store the current preferences of the data subject, allowing them to be operationally applied to communication processes, for example with regard to email delivery or the enabling/disabling of tracking.
However, the platform is not designed as a dedicated consent history and auditing system: it does not natively maintain a complete and evidentiary historical record of expressed preferences, subsequent changes, timestamps, notice versions, and the elements required for ex post documentary reconstruction.
For these purposes, the use of an external dedicated Consent Management platform is recommended, integrated with magnews and, where applicable, with other systems, in order to centrally maintain the history of preferences and make the updated status available to all systems processing contact data.