Data Retention and Deletion Policy
MarginPatrol | Version 1.0 | Prepared 08 August 2026
Publication date: 02.09.2026. Effective date: 02.09.2026. Canonical page: https://marginpatrol.com/data-deletion.
1. Scope and principles
This policy is issued by the operator identified in the Legal Notice, trading as MarginPatrol. It applies to retained store records, calculations, source data, credentials, generated files and relevant account/support/security information. Questions and requests: support@marginpatrol.com.
We retain data only for a specified service purpose, valid Merchant instruction or identified legal basis, and for no longer than needed. The DPA governs Merchant Personal Data processed on instruction; our own minimum contract, billing and compliance records are governed by the Privacy Policy and applicable law.
A plan's history limit controls viewing depth, not necessarily physical retention. Archive access is a bounded service, not an agreement to keep every record forever. Pseudonymised data remains protected personal data where it is still identifiable. Only genuinely irreversible, non-identifying aggregate information may be treated differently, and applicable Google-derived-data restrictions continue to apply.
2. Actions that must not be confused
| Action | Immediate effect | What it does not mean |
|---|---|---|
| Stop renewal | Starts the confirmed billing process; existing granted access continues to its boundary | Does not by itself delete data or reverse earlier charges |
| End monitoring access | Stops new monitoring and leaves the instructed permitted read-only archive | Does not make an old calculation current or complete |
| Disconnect an advertising source | Stops future use of that connection and removes unnecessary credential access | Does not silently remove historic spend from retained results |
| Uninstall or revoke store access | Stops store access, including future mobile access, and the affected source processing | Does not promise remote erasure of a screenshot or immediate disappearance of legally retained records |
| Request store-data deletion | After verifying authority, stops affected access, new sync, notification delivery and exports; starts erasure | Does not authorise deletion of another store or guarantee an undo function |
A store-wide deletion instruction applies to the relevant store's retained data across applicable historical installation generations. Reinstalling does not cancel a valid privacy instruction or permit deleted data to be silently restored. Where law or a platform instruction requires erasure, an ordinary archive preference does not override it.
3. Implemented retention schedule
The periods below are maximum technical retention periods for the reviewed release. A shorter applicable legal, platform or valid deletion deadline takes priority.
| Category | Maximum period and trigger |
|---|---|
| Active store records, cost/source history, calculations and signals | While required for the active instructed service or an instructed read-only archive; deleted sooner following a valid deletion instruction or mandatory platform request |
| OAuth callback state | One day for callback replay prevention |
| Sanitised webhook inbox and webhook deduplication identifiers | 90 days for replay suppression and operational evidence |
| Raw provider diagnostic responses and detailed background-job errors | 30 days from creation |
| Background-job metadata | 180 days from creation |
| Standard API idempotency records | One day; billing idempotency records up to 30 days |
| Business and privacy export files | Seven days after generation; signed download access can expire earlier |
| CSV import objects | Up to 24 hours and deleted after a successful commit |
| Provider import files | Up to 48 hours and deleted after import |
| Notification-provider events | 30 days; notification attempts 180 days; bounded notification audit metadata 730 days |
| Application logs | 30 days; security logs 180 days |
| Sanitised audit evidence and financial/access audit metadata | 730 days |
| Minimal deletion receipt | 730 days; it records scope, timing and result without retaining deleted content |
| Daily database backups | 14 days |
| Weekly database backups | 28 days |
| Store data after an accepted deletion instruction | Active records, caches, credentials, scheduled work and generated files removed without undue delay and no later than 30 calendar days; a shorter applicable requirement prevails |
A plan's 90-day or 365-day history limit controls the data available in product views; it is not a separate physical deletion deadline. Archive access does not reset a retention period merely because Billing is opened. Retention jobs, private-object cleanup, signed-download expiry and deletion verification are monitored as operational controls.
4. Owner-requested deletion and the earlier seven-day window
The owner can request deletion through Settings → Data & Privacy or support. We verify authority proportionately; paid access is not required. Do not send tokens, customer lists or identification documents beyond what is specifically and securely requested.
After acceptance, access and new processing stop immediately except operations needed to verify and execute deletion or comply with law. The deletion process may include a security/administrative window of no more than seven calendar days before irreversible active erasure, consistent with the previously described owner-requested grace window. This window is included within, not added to, the 30-day deadline. It is not a promise of an available cancellation or restoration feature.
Mandatory individual or Shopify instructions are not delayed by an optional grace period. A shorter legal deadline, an urgent valid objection or an applicable platform rule takes priority. We explain the expected completion, distinguish active deletion from backup expiry, and provide an appropriate confirmation of the completed scope.
Where a rights request is not yet sufficiently identified, we seek proportionate clarification promptly. We do not use unnecessary identity questions to restart or avoid a running statutory or platform deadline.
5. Shopify privacy requests and uninstall
Shopify may send instructions to provide customer data, erase customer-related data or erase store data after uninstall. We process the applicable instruction and record its outcome even where no matching customer contact record is held. Identifiers or related order records can still be personal data.
Applicable Shopify requests are completed within the platform's 30-day period from receipt, subject to a specifically applicable legal retention requirement and any shorter law. The optional owner-deletion window does not add time. A successful acknowledgement or queued job is not a completion certificate.
Uninstall does not guarantee the precise moment of permanent erasure in every storage layer. It stops access and triggers the applicable lifecycle. A later reinstall cannot override a received valid redaction instruction; overlapping lifecycle states require preserving valid rights without reintroducing erased data.
6. Google and other advertising data
The schedule covers imported account/campaign metadata, dated spend, financial derivatives and credentials. Disconnecting a source removes future access to it but retained historical records can remain for an active authorised calculation or archive until deletion applies.
If an authorisation is shared across genuinely valid store connections, revoke the affected store's use immediately without representing the continued necessary authorisation for another store as deleted. Credentials no longer needed by any authorised connection are removed under the schedule. Global revocation through the provider can affect other connections using that same authorisation.
The approved provider and transfer register must identify where Google-derived data is actually processed. Retention is not extended by sending a copy to another provider; corresponding deletion instructions apply to subprocessors. Copies independently held in a Merchant's own workspace or downloads are subject to that Merchant's duties and the recipient's applicable terms.
7. Return, deletion and exceptions
The Merchant may request return of available data in a commonly used machine-readable form and then deletion, or deletion without return. A statutory rights export is not dependent on purchasing an advanced commercial export feature. Some records can no longer exist under an already expired retention period; we explain that limitation rather than reconstruct personal data from unrelated sources.
We retain only the minimum operator records that an identified accounting, tax, regulatory or other legal duty requires, for the period that duty prescribes. Where a live dispute creates a lawful preservation need, restrict the relevant operator records, document the basis, review it periodically and release the hold when it ends. These purposes do not authorise retaining the entire Merchant dataset as processor against a valid deletion instruction.
The operator’s own tax records, where required, include primary documents and other records used to establish its tax-reporting figures under Article 44.1 of the Tax Code of Ukraine. Article 44.3 sets minimum retention periods by category: 1,095 days for records outside the longer-period categories; 1,825 days for records of the entities expressly covered by Article 44.3.2, which is not a blanket rule for an FOP; and 2,555 days for records covered by Article 44.3.1, where applicable. For records used in a tax return, the period runs from submission of that return or, if it was not submitted, its statutory filing deadline. For documents connected with other laws supervised by tax authorities, it runs from the relevant transaction or, for permits, expiry. Statutory suspension of the limitation period can extend these periods. Under Article 44.4, records relevant to a tax audit, administrative appeal or court proceeding must also be kept until the process and applicable appeal period end, at least through the Article 44.3 minimum. These rules justify retaining only the operator records to which they actually apply, not the whole Merchant dataset. We can explain a retained category and basis to the requester unless prohibited by law.
Minimal deletion evidence should record request/scope reference, time and result without retaining deleted content. Even a coded reference is treated as personal data if linkability remains. It is retained only for a documented compliance purpose and period.
8. Backups, failures and local copies
Backups are protected from routine browsing and are not an alternative active archive. Removal can occur through secure erasure, verified scheduled expiry or technically effective destruction of the relevant decryption capability. Calling a backup encrypted does not prove that it has been deleted.
When recovery occurs, valid deletion instructions are reapplied before restored data is made available for normal use. Failed deletion is escalated and retried with the applicable deadline preserved. The owner is not told "deleted" merely because access was disabled or one processing attempt ended.
We cannot remove copies a Merchant has downloaded, independently sent or captured in a screenshot. An offline device may retain already displayed information until it reconnects or local data is removed; future server access is revoked. Recipients remain responsible for their own copies under the applicable law and instructions.
9. Changes and contact
A material retention change requires review, an updated notice and the required contractual/instruction process. Longer retention is not imposed retrospectively by silently changing this page. Earlier deletion remains subject to lawful instructions, advance service notice and applicable duties.
Contact support@marginpatrol.com. The Privacy Policy explains individual rights and complaints. The DPA governs return and deletion of data processed for a Merchant. The technical periods above are implemented for the reviewed release; legal approval and public activation of this document remain separate gates.