Martez

Privacy Policy

Version 2 — Effective October 7, 2026

This Privacy Policy explains how Martez (operated by Raphael Kagermeier, sole proprietor doing business as Performromance) collects, uses, stores and shares personal data when you use the Martez service ("Martez", the "Service") or visit our marketing website. It is written to comply with the EU General Data Protection Regulation (Regulation (EU) 2016/679, "GDPR"), the Austrian Data Protection Act (Datenschutzgesetz, "DSG"), and the Google API Services User Data Policy.

If you only want to know what we do with data we receive from Google APIs (in particular Google Ads), jump to Section 3: Google API Services and Limited Use. If you only want to know what we do with data we receive from the Meta Marketing API (Meta Ads, via Facebook Login or a Meta Business Manager System User token), jump to Section 4: Meta Platform Data and the Marketing API.

1. Who we are

The controller of your personal data within the meaning of Art. 4(7) GDPR is:

Raphael Kagermeier (sole proprietor, doing business as Performromance)
Neubaugasse 24
8020 Graz
Austria

  • Email: office@performromance.com
  • Phone: +43 680 2200968
  • VAT ID: ATU76150157
  • Supervisory authority: Magistrat der Landeshauptstadt Graz
  • Chamber: Wirtschaftskammer Steiermark

Data Protection Officer. As a sole proprietor we are not required to appoint a formal Data Protection Officer under Art. 37 GDPR, and we have not appointed one voluntarily. For any data-protection question or request, please contact us directly at the address above.

As the controller is established within the European Union (Austria), no representative under Article 27 GDPR is required.

2. Scope of this policy

This policy applies to:

  • Personal data of individuals who register for or use the Martez application (account holders and their team members);
  • Third-party data that you, as a Martez customer, choose to import into the Service through integrations such as Google Ads, Meta Ads, Matomo, Digistore24 and KlickTipp;
  • Visitors to our marketing website.

When you import third-party data through an integration, you act as the data controller with respect to that data and Martez acts as your data processor. When you are an account holder or marketing-site visitor, Martez acts as the controller.

3. Google API Services and Limited Use

This section describes specifically how Martez handles data received from Google APIs when you connect a Google Ads account through OAuth.

3.1 Limited Use disclosure (canonical Google language)

> Martez's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

3.2 OAuth scopes we request

When you connect a Google Ads account to Martez, we request the following scopes:

  • openid — Identifies you to Martez via a signed Google ID token, so we can link the connection to your Google identity.
  • email — Lets Google include your verified email address in the ID token, so we can show you which Google account is connected and contact you about that connection.
  • profile — Requested for technical compatibility with the OAuth library Martez uses (Laravel Socialite), which requires the profile claims to be present in the ID token in order to construct a valid user object at sign-in. Although the profile scope is requested, Martez does not read or persist the profile claims (name, locale, profile picture URL) — only the OpenID sub claim (your Google account identifier) and the verified email address are retained with the integration. We do not call Google's userinfo endpoint or any other Google profile-specific API.
  • https://www.googleapis.com/auth/adwords: Read data from the Google Ads accounts you select, so Martez can import campaign, ad-group and ad performance data for attribution and cost analytics. Google designates this scope as a sensitive scope under the Google API Services User Data Policy; Section 3.5 of this Privacy Policy sets out the additional Limited Use commitments that apply. Google does not offer a separate read-only variant of this scope; Martez uses it primarily to read data and, only on your explicit request, to pause or resume your own campaigns, ad groups or ads (see clarification below).

Beyond openid, email, profile and adwords above, we do not request any other Google scope. In particular, we do not request Drive, Gmail, Calendar, Contacts, YouTube or any other Google service scope.

Martez uses the adwords scope primarily to read performance data. The only write operation Martez performs is a user-initiated delivery-status change: when you explicitly click Pause or Resume on one of your own campaigns, ad groups or ads inside Martez, we send a single status update to the Google Ads API on your behalf. Martez does not create, delete, or otherwise modify campaigns, budgets, bids, targeting or creatives. Should the scope of our write operations change, we will update this Privacy Policy and notify connected Customers in advance.

3.3 What Google data we actually receive

After you grant consent, Martez calls the Google APIs to receive:

  • From Google's OpenID Connect endpoints: your Google account identifier (sub claim), your verified email address (email_verified == true), and the issuer/audience metadata required to validate the ID token. The basic profile claims that Google includes in the ID token under the profile scope are not read or persisted by Martez (see Section 3.2).
  • From the Google Ads API at connect time: the list of Google Ads accounts accessible to you (customers:listAccessibleCustomers) and, for each selected account, the customer ID, descriptive name, currency code, time zone, manager flag, test-account flag and status.
  • From the Google Ads API during synchronization: campaign, ad-group and ad metadata (ID, name), campaign delivery status (campaign.status) and performance metrics (cost_micros, impressions, clicks).

We do not request, store or process any other categories of Google user data.

3.4 How we use Google data (sole purpose)

We use Google user data only to provide the Martez service to the customer who connected the account. Concretely:

  • We display your Google Ads accounts so you can select which ones to import into a Martez project.
  • We import campaign, ad-group, ad and spend records into your project so that Martez can calculate attribution, ROAS and our proprietary Average Cost per Contributing Touchpoint (ACpCT) metric for the campaigns you run.
  • We store the OAuth refresh and access tokens we receive so we can continue to fetch updates on your behalf without asking you to log in again on every sync (legal basis: Article 6(1)(b) GDPR — performance of the contract under which the Customer connected the Google Ads account). Tokens are encrypted at rest at the application layer using Laravel's encrypted casts, keyed by the application's APP_KEY, and the underlying AWS RDS PostgreSQL volume is itself encrypted at rest (AES-256); see Section 12 — Security for the full set of technical and organizational measures.

3.5 Limited Use commitments

In line with the Limited Use requirements, we explicitly commit:

  • No advertising. We do not use Google user data for advertising, retargeting or to build advertising audiences.
  • No selling. We do not sell Google user data.
  • No AI/ML training. We do not use, retain, or transfer Google user data to develop, improve, train, or fine-tune any generalized or non-personalized artificial intelligence or machine-learning model, whether operated by Martez, by any sub-processor listed in Section 8, or by any other third party. This commitment applies to the adwords sensitive scope and to the OpenID Connect identity claims listed in Section 3.3.
  • No human reading. No human at Martez reads Google user data, except (a) with the explicit prior request or consent of the Customer or User to whom the data relates, including support requests that cannot be fulfilled without inspecting the data; (b) for security or abuse investigations strictly necessary to protect the Service or its users; (c) where we are compelled to do so by applicable law (for example, a binding court order or regulatory request); or (d) where the data has been aggregated or de-identified so that it can no longer be linked to an individual person or to a specific Google account, and is used only for internal operations such as capacity planning. This restriction applies to all Martez personnel, contractors, and sub-processors.
  • No transfers to third parties. We do not transfer Google user data to third parties, except to the sub-processors listed in Section 8: Sub-processors where strictly necessary to operate the Service, and always under written processor agreements. In particular: AWS (eu-central-1) receives Google user data in the course of providing compute, database and object-storage services for the Service; CloudFront and Cloudflare carry application pages containing Google user data in encrypted transit, and this data is not cached or stored there. Resend, Sentry, Slack and Matomo do not receive Google user data; Sentry payloads are scrubbed of Google user data before transmission, and Slack receives only operational metadata such as "sync failed for project X". We do not transfer Google user data to any party for AI/ML training, advertising, audience-building, profiling, credit-scoring, or any purpose other than operating the Service for the connecting Customer.
  • Incident notification. Where we become aware of a personal-data breach (within the meaning of Article 4(12) GDPR) that affects Google user data, we notify the Austrian Data Protection Authority within 72 hours under Article 33 GDPR and notify the affected Customer without undue delay and in any event within 48 hours of becoming aware, as set out in our Data Processing Agreement (Annex 1 to the Terms of Service, §A1.9). Where the breach is likely to result in a high risk to the rights and freedoms of natural persons, we also notify the affected Users in accordance with Article 34 GDPR.

3.6 Revocation and disconnect

You can disconnect Martez from your Google account at any time, in either of two ways:

  • From Google: at https://myaccount.google.com/permissions, find "Martez" and select "Remove access".
  • From Martez: in Project Settings → Integrations, choose "Disconnect" on the Google Ads integration.

3.7 Deletion of Google-derived data

For deletion timelines triggered by termination of the Service or your Martez account (rather than by a written deletion request), see Terms of Service §15.

When you disconnect a Google Ads integration:

  • We immediately clear the OAuth refresh and access tokens we hold for that integration; Martez can no longer call the Google Ads API on your behalf.
  • The campaign, ad-group, ad and spend records we have already imported remain in your Martez project so that historical reporting is preserved, until you delete the project, delete the specific records, or submit a deletion request to office@performromance.com.
  • Upon a written deletion request sent to office@performromance.com, we delete the Google-derived data we hold from active production systems within thirty (30) days of receipt of the request. Where the data is also present in routine encrypted backups, the data persists in those backups until the backup-retention window expires (see Section 10 — Retention) and is then purged; pending purge, backups remain encrypted, are not actively processed, and are subject to the security obligations of this Privacy Policy. Where applicable law requires longer retention of specific records, we restrict processing of those records instead of deleting them, and resume deletion once the legal retention period ends.

4. Meta Platform Data and the Marketing API

This section describes specifically how Martez handles data received from the Meta Marketing API (Graph API) when you connect a Meta Ads account through OAuth or through a Meta Business Manager System User token. It is written to satisfy the obligations imposed on Martez as a developer under the Meta Platform Terms and the Meta Developer Policies, as those documents stand on the effective date of this Privacy Policy.

4.1 Platform Terms compliance disclosure

Martez's access to and use of information received from the Meta Marketing API is governed by the Meta Platform Terms and the Meta Developer Policies. We process Meta Platform Data only for the permitted purposes documented in this Privacy Policy and in the Service, and we will discontinue processing on the timelines set out below.

4.2 OAuth scopes and permissions we request

When you connect a Meta Ads account to Martez, either through Facebook Login to authorise access to your Meta Ads accounts or by pasting a System User access token issued from your Meta Business Manager, Martez requests the following permissions:

  • ads_read — Read campaign, ad-set, ad metadata and performance metrics (cost, impressions, clicks) from the ad accounts you authorise, so Martez can import them for attribution and cost analytics.
  • business_management — Read the list of Meta Businesses and ad accounts accessible to you (or to the System User you authorise), so we can present an ad-account picker and import data from the accounts you select.
  • public_profile — Receive a stable Meta user identifier (Meta user ID) to identify the connecting account in Martez and to validate token ownership via /debug_token. We do not currently call /me?fields=name,picture and do not store the user's name or profile picture.
  • ads_management — Apply the delivery-status changes (pause / resume) that you explicitly initiate in Martez to the campaigns, ad sets and ads in the ad accounts you authorise. Martez uses this permission only for user-initiated pause/resume; it does not create, delete, or edit budgets, bids, targeting or creatives.

Martez deliberately does not request the email permission, the pages_ family, the instagram_ family, or any other Meta permission outside the four listed above. Aside from ads_management, Martez uses these permissions to read data only. The sole write operation Martez performs is a user-initiated delivery-status change: when you explicitly click Pause or Resume on one of your own campaigns, ad sets or ads inside Martez, we send a single status update to the Meta Marketing API on your behalf. Martez does not create, delete, or otherwise modify campaigns, budgets, bids, targeting or creatives. Should the scope of our write operations change, we will update this Privacy Policy and notify connected Customers in advance.

4.3 What Meta data we actually receive

After you grant consent, Martez calls the Meta Marketing API to receive:

  • From Meta's OAuth endpoints (/oauth/access_token and /debug_token): your Meta user ID, the app_id of the Martez Meta application, the list of granted permissions (scopes), the long-lived access token, and the token's data_access_expires_at / expires_at metadata used to validate token integrity via an app-secret-proof round-trip.
  • From the Meta Marketing API at connect time: the list of ad accounts accessible to you (via /me/adaccounts for the standard OAuth path, or via /{business_id}/owned_ad_accounts and /{business_id}/client_ad_accounts for the System User path), and for each account the account ID, descriptive name, account status, currency, time-zone name, and the parent Business ID and name.
  • From the Meta Marketing API during synchronisation: campaign / ad-set / ad metadata (ID, name, status, schedule) and performance metrics (spend, impressions, clicks and the metric aggregates we expose in the Martez reports).

We do not request, store or process any other categories of Meta user data. In particular, we do not request page content, message content, audience definitions, or end-user-level conversion data from Meta.

4.4 How we use Meta data (sole purpose)

We use Meta Platform Data only to provide the Martez service to the Customer who connected the account. Concretely:

  • We display your Meta Businesses and ad accounts so you can select which ones to import into a Martez project.
  • We import campaign, ad-set, ad and spend records into your project so that Martez can calculate attribution, ROAS and our proprietary Average Cost per Contributing Touchpoint (ACpCT) metric for the Meta campaigns you run.
  • We use ads_management to pause or resume a campaign, ad set or ad in an ad account you authorise, only when you explicitly initiate that change in Martez.
  • We store the long-lived access token (and, on the System User path, the pasted System User token) encrypted at the application layer so we can continue to fetch updates on your behalf without asking you to re-authorise on every sync (legal basis: Article 6(1)(b) GDPR — performance of the contract under which the Customer connected the Meta Ads account).

We do not combine Meta Platform Data with data from other Customers, and we do not derive cross-Customer audiences or insights from it.

4.5 Limited use commitments for Meta data

Consistent with the Meta Platform Terms (in particular section 3 — Permitted Uses, and section 3.a — restrictions on data use) and the Meta Developer Policies (in particular Ads API 10.7 — sole-purpose use of advertiser campaign data), we explicitly commit:

  • No advertising other than the Customer's own. We use Meta Platform Data only to report on the Meta campaigns the Customer themselves runs and to pause or resume those campaigns, ad sets and ads at the Customer's explicit request. We do not use Meta Platform Data to target advertising, build advertising audiences, perform retargeting, or to optimise or measure campaigns of any party other than the Customer who connected the ad account.
  • No selling. We do not sell Meta Platform Data.
  • No AI/ML training. We do not use Meta Platform Data to develop, improve, or train generalised or non-personalised artificial intelligence or machine-learning models, whether operated by Martez or by any third party.
  • No human reading. No human at Martez reads Meta Platform Data, except in any of the following narrowly defined cases: (a) you explicitly request support that requires us to look at the data; (b) we need to investigate a suspected security incident or abuse of the Service; (c) we are compelled to do so by applicable law (for example, a binding court order); (d) the data has been aggregated or de-identified so that it is no longer linked to a Meta user or to a specific ad account.
  • No transfers to third parties other than sub-processors. We do not transfer Meta Platform Data to third parties, except to the sub-processors listed in Section 8 — Sub-processors where strictly necessary to operate the Service, and always under written processor agreements that flow down the obligations of the Meta Platform Terms.
  • Audit cooperation. We will cooperate with audits or reasonable enquiries by Meta in respect of our compliance with the Meta Platform Terms and the Meta Developer Policies, including by providing the necessary documentation and access in line with section 7 of the Meta Platform Terms.

4.6 Security of Meta tokens and Meta Platform Data

Long-lived OAuth access tokens and pasted System User tokens are stored using Laravel's encrypted casts, keyed by the application's APP_KEY, in line with the obligation in section 6.a of the Meta Platform Terms to protect Meta user IDs, access tokens and app secrets. We validate token integrity through Meta's /debug_token endpoint using an app-secret-proof (app_id|app_secret) on every connect and on every API call by re-deriving an appsecret_proof HMAC against the token and the application secret. Pasted System User tokens may be non-expiring depending on how the Customer's Meta Business Manager System User is configured; Martez does not extend or alter their lifetime. The full technical and organisational measures applicable to Meta Platform Data are described in Section 12 — Security.

4.7 Revocation and disconnect (Meta)

You can disconnect Martez from your Meta account at any time, in either of two ways:

  • From Meta: at https://www.facebook.com/settings?tab=business_tools ("Business Integrations") or at https://www.facebook.com/settings?tab=applications ("Apps and Websites"), depending on where Meta lists your connection. Find "Martez" and choose "Remove". This revokes the long-lived access token on Meta's side.
  • From Martez: in your project settings under Integrations, choose "Disconnect" on the Meta Ads integration. Martez will immediately delete the long-lived access token (or pasted System User token) from our records; we can no longer call the Meta Marketing API on your behalf.

4.8 Deletion of Meta-derived data

For deletion timelines triggered by termination of the Service or of your Martez account (rather than by a written deletion request from an individual), see Terms of Service §15.

When you disconnect a Meta Ads integration, or when a Meta user uses the Business Integrations page to remove Martez:

  • We immediately clear the long-lived OAuth access token (or pasted System User token) we hold for that integration; Martez can no longer call the Meta Marketing API on your behalf.
  • The campaign, ad-set, ad and spend records we have already imported remain in your Martez project so that historical reporting is preserved, until you delete the project, delete the specific records, or submit a deletion request to office@performromance.com.
  • Upon a written deletion request, we delete the Meta-derived data we hold within 30 days, except where we are required by law to retain specific records for longer (in which case we restrict processing instead).

If you are an individual Meta user (rather than a Martez Customer) and you wish to know whether Martez holds Meta Platform Data linked to your Meta user ID, or to request its deletion, please write to office@performromance.com with the subject "Meta Data Deletion Request" and we will respond within 30 days. We will require sufficient information to locate the data (typically your Meta user ID and the name of the Martez Customer whose ad accounts you administered or interacted with), and we may rely on the Martez Customer to verify your identity.

Data Deletion Callback (Meta-initiated). Martez also exposes a programmatic Data Deletion Callback endpoint at /integrations/meta-ads/data-deletion. When a Meta user removes Martez from their Facebook Business Integrations, Meta delivers a signed_request POST to this endpoint; Martez verifies the request against the Martez Meta-app secret (HMAC-SHA256), processes the deletion, and returns a JSON response of the form {url, confirmation_code} pointing to a public status page at /data-deletion-status/{confirmation_code} where the requesting user can confirm the status of the request. Deletions delivered through this callback are processed on the same 30-day timeline as written deletion requests.

5. Data we collect (other than Google or Meta data)

5.1 Account and personal data we collect as controller

  • Identity & contact data — name, email address, password hash, profile preferences. Source: you, at sign-up.
  • Authentication metadata — IP address at sign-in, session timestamps, multi-factor authentication state. Source: automatically, on use.
  • Billing data — invoice address, VAT number, payment status (we do not store full card numbers). Source: you, on subscribing.
  • Support data — email correspondence, error reports you choose to send. Source: you, when you contact us.
  • Diagnostic data — server log files (IP, request path, user agent, status code, latency). Source: automatically, on use.

5.2 Customer-imported data we process as processor

When you connect an integration, you instruct Martez to import data from a third-party platform into your project. The categories vary by integration but typically include:

  • Google Ads — customer/campaign/ad-group/ad metadata, cost, impressions, clicks (see Section 3).
  • Meta Ads — connecting-user identity (Meta user ID from public_profile); accessible-business / accessible-ad-account identifiers (Business ID, Business name, Ad-account ID, account name, currency, time-zone, account-status flag); campaign / ad-set / ad metadata and performance metrics (spend, impressions, clicks) (see Section 4).
  • Matomo — visitor IDs, pageview events, goal/conversion events, UTM parameters, referrer URLs.
  • Digistore24 — order/transaction records, payment status, gross/net amounts.
  • KlickTipp — subscriber identifiers, tag/list membership, event timestamps.

This data may indirectly identify an individual (for example, a Matomo Visitor ID linked to a UTM-tagged click). You remain the controller of this data; Martez processes it on your documented instructions under a Data Processing Agreement.

5.3 Marketing website

When you visit our marketing website we process technical connection data (IP address, user agent, time of request) for the purpose of delivering the page, securing the site and producing aggregate statistics. See Section 13 — Cookies and marketing-site analytics.

6. Legal bases per processing purpose

We process personal data only where one of the legal bases in Art. 6(1) GDPR applies. The mapping below covers every processing purpose described in this policy.

  • Creating and operating your Martez account — Art. 6(1)(b) Contract. Necessary to perform the SaaS subscription you have entered into with us.
  • Authenticating you (login, MFA, session management) — Art. 6(1)(b) Contract. Necessary to provide the Service.
  • Storing the OAuth refresh/access tokens for an integration you connect — Art. 6(1)(b) Contract. The only way to deliver the integration feature you have requested.
  • Fetching Google Ads / Meta Ads / Matomo / Digistore24 / KlickTipp data on your instruction — Art. 6(1)(b) Contract (between Martez and you) and Art. 28 GDPR (between you and Martez, as your processor, vis-à-vis the data subjects in the imported data). We act on your documented instructions.
  • Calculating ACpCT, ROAS, attribution and other analytics for your project — Art. 6(1)(b) Contract. Core product functionality you have subscribed to.
  • Sending transactional emails (sign-up confirmation, password reset, billing notices, integration health alerts) — Art. 6(1)(b) Contract. Necessary to deliver and administer the Service.
  • Sending product update emails to existing customers about features they already use — Art. 6(1)(f) Legitimate interest. Our legitimate interest in informing customers about the Service they pay for; you can opt out at any time.
  • Server log files for failure analysis and security — Art. 6(1)(f) Legitimate interest. Our legitimate interest in keeping the Service operational and secure; retention strictly limited (see Section 10).
  • Error and exception tracking via Sentry — Art. 6(1)(f) Legitimate interest. Our legitimate interest in detecting and fixing software defects.
  • Issuing invoices and meeting accounting obligations — Art. 6(1)(c) Legal obligation. Austrian Federal Fiscal Code (BAO) and Commercial Code (UGB) require retention of business records.
  • Responding to data-subject requests, regulator requests, court orders — Art. 6(1)(c) Legal obligation. Compliance with GDPR and other applicable law.
  • Marketing-site analytics (Matomo, anonymized) — Art. 6(1)(f) Legitimate interest or, where required, Art. 6(1)(a) Consent. Where the law requires consent (e.g. non-essential cookies), we ask for it via the cookie banner.

We do not rely on consent (Art. 6(1)(a) GDPR) as the legal basis for any processing of Google user data or Meta Platform Data; we rely on the contract you enter into with us when you sign up for Martez and connect the integration.

7. Recipients and disclosures

Martez does not sell personal data of any kind, to any party, under any circumstance.

We share personal data only with:

  • The sub-processors listed in Section 8, strictly to operate the Service;
  • Your own team members and project collaborators, to the extent you grant them access in Martez;
  • Professional advisers (accountants, lawyers) under confidentiality, where required;
  • Public authorities, where we are legally compelled.

We never sell personal data.

8. Sub-processors

We engage the following sub-processors to operate Martez. All sub-processors are bound by written data-processing agreements that impose obligations equivalent to those in this policy.

  • Amazon Web Services EMEA SARL (AWS Lambda, RDS PostgreSQL, S3)
  • Role: application compute, database, file storage.
  • Hosting region: eu-central-1 (Frankfurt, Germany).
  • Transfer mechanism: EU hosting; AWS EU Data Boundary; EU SCCs (Art. 46 GDPR), Module 2 (Controller-to-Processor) for any incidental support access from outside the EEA.
  • Amazon CloudFront
  • Role: content delivery network for public static assets and delivery of application pages.
  • Hosting region: global edge network.
  • Transfer mechanism: EU SCCs (Art. 46 GDPR), Module 2 (Controller-to-Processor); Google user data and Meta Platform Data pass through in encrypted transit and are not cached or stored there.
  • Cloudflare, Inc.
  • Role: reverse proxy, TLS termination and web application firewall in front of the martez.io hosts.
  • Hosting region: United States.
  • Transfer mechanism: EU SCCs (Art. 46 GDPR), Module 2 (Controller-to-Processor); Google user data and Meta Platform Data pass through in encrypted transit and are not cached or stored there.
  • Resend (Resend.com Inc.)
  • Role: transactional email delivery.
  • Hosting region: United States.
  • Transfer mechanism: EU SCCs (Art. 46 GDPR), Module 2 (Controller-to-Processor); no Google user data and no Meta Platform Data is sent in transactional email payloads.
  • Sentry (Functional Software Inc.)
  • Role: application error and exception tracking.
  • Hosting region: United States.
  • Transfer mechanism: EU SCCs (Art. 46 GDPR), Module 2 (Controller-to-Processor); Google user data and Meta Platform Data are excluded from error payloads.
  • Slack Technologies LLC
  • Role: internal health-alert notifications.
  • Hosting region: United States.
  • Transfer mechanism: EU SCCs (Art. 46 GDPR), Module 2 (Controller-to-Processor); only operational metadata (e.g. "sync failed for project X"), no Google user data and no Meta Platform Data, is sent.
  • Matomo (InnoCraft Ltd. / self-hosted instance)
  • Role: marketing-site analytics (consent-gated) and Customer-connectable in-app integration.
  • Hosting region: EU (self-hosted on AWS eu-central-1 for the marketing-site instance; Customer-controlled location for Customer-connected instances).
  • Transfer mechanism: EU hosting for the marketing-site instance; for Customer-connected instances, the Customer determines the location and any transfer mechanism. EU SCCs (Art. 46 GDPR) apply to any incidental support access from outside the EEA.

We do not transfer Google user data or Meta Platform Data to any sub-processor for AI/ML training, advertising, or any purpose other than operating the Service.

9. International transfers

Personal data is stored in the European Union (AWS eu-central-1, Frankfurt). Where we use sub-processors established outside the EEA (currently the United States), we rely on the 2021 EU Standard Contractual Clauses (EU SCCs, Commission Implementing Decision (EU) 2021/914), Art. 46 GDPR, as the transfer mechanism. The applicable module is:

  • Module 2 (Controller-to-Processor) for our relationship with Resend, Sentry, Slack, CloudFront and Cloudflare.

We do not currently rely on the EU–US Data Privacy Framework adequacy decision as the sole transfer mechanism; SCCs apply in any case.

Where required, we apply supplementary technical measures, including encryption in transit (TLS 1.2+) and at rest, and we restrict the categories of data sent to non-EEA sub-processors as described in Section 8.

For each non-EEA transfer, Martez has performed a Transfer Impact Assessment consistent with EDPB Recommendations 01/2020 on supplementary measures, considering the legal regime of the recipient country and the supplementary technical, contractual, and organizational measures applied.

10. Retention

We retain personal data only as long as necessary for the purpose for which it was collected, or as required by law. The list below sets out our standard retention periods.

  • Account data (name, email, password hash, preferences) — for the lifetime of the account; deleted within 30 days after you close the account.
  • OAuth refresh and access tokens (for any integration, including Google) — until you disconnect the integration; cleared immediately on disconnect.
  • Long-lived Meta OAuth access tokens and pasted System User tokens — until you disconnect the integration or remove Martez from your Facebook Business Integrations page; cleared immediately on disconnect.
  • Google-derived campaign / ad-group / ad / spend records — until you delete the project, delete the records, or submit a deletion request; deleted within 30 days of a request (see §3.7).
  • Meta-derived campaign / ad-set / ad / spend records — until you delete the project, delete the records, disconnect the integration with deletion election, or submit a deletion request; deleted within 30 days of a request (see §4.8).
  • Other integration data (Matomo, Digistore24, KlickTipp) — until you delete the project, delete the records, or submit a deletion request; deleted within 30 days of a request.
  • Support correspondence — 24 months after the ticket is closed.
  • Server log files — 30 days.
  • Sentry error events — 90 days.
  • Billing records and invoices — 7 years (Austrian Federal Fiscal Code, § 132 BAO).
  • Backups — rolling 35 days, after which data is overwritten.

If you request deletion of data that is also held in a backup, we will restrict processing of that data and let it expire from the backup rotation, rather than restoring backups to delete a single record.

11. Your rights

Subject to the conditions in the GDPR, you have the following rights with respect to your personal data:

  • Right of access (Art. 15 GDPR) — to obtain confirmation of whether we process personal data about you, and a copy of that data.
  • Right to rectification (Art. 16 GDPR) — to have inaccurate or incomplete data corrected.
  • Right to erasure (Art. 17 GDPR), also known as the "right to be forgotten".
  • Right to restriction of processing (Art. 18 GDPR).
  • Right to data portability (Art. 20 GDPR) — to receive your data in a structured, commonly used, machine-readable format.
  • Right to object (Art. 21 GDPR) to processing based on legitimate interests, including direct-marketing purposes.
  • Right to withdraw consent (Art. 7(3) GDPR), where processing is based on consent; withdrawal does not affect the lawfulness of processing carried out before withdrawal.
  • Right not to be subject to automated decision-making producing legal or similarly significant effects (Art. 22 GDPR). Martez does not carry out any such automated decision-making.

To exercise these rights, contact us at office@performromance.com. We respond to requests within one month of receipt (extendable by up to two further months for complex requests, in which case we will inform you within the first month).

You also have the right to lodge a complaint with a supervisory authority (Art. 77 GDPR). The competent authority for us is:

> Österreichische Datenschutzbehörde (Austrian Data Protection Authority)
> Barichgasse 40–42
> 1030 Wien
> Austria
> Phone: +43 1 52 152-0
> Email: dsb@dsb.gv.at
> Web: https://www.dsb.gv.at

You may also complain to the supervisory authority in your EU country of residence or workplace.

12. Security

We apply the following technical and organizational measures (Art. 32 GDPR) to protect personal data:

  • Encryption in transit: TLS 1.2 or higher for all connections to Martez and to upstream APIs.
  • Encryption at rest: OAuth tokens and other sensitive integration credentials (including Google OAuth refresh/access tokens, Meta long-lived OAuth access tokens, and pasted Meta Business Manager System User access tokens) are stored using Laravel's encrypted casts, keyed by the application's APP_KEY. Database and object-storage volumes are encrypted at rest by AWS (AES-256).
  • Access controls: role-based access in the application; production database and infrastructure access restricted to the operator (sole proprietor) over SSH/IAM with multi-factor authentication; principle of least privilege.
  • Tenancy isolation: every record is scoped to a Martez project; cross-project access is blocked at the ORM and query level.
  • Backups: automated, encrypted, retained on a 35-day rolling schedule and tested periodically for restore.
  • Logging and monitoring: application errors are tracked in Sentry; access to production infrastructure is logged.
  • Patching: operating system, runtime and library dependencies are updated regularly; security advisories are reviewed on receipt.

We have not obtained SOC 2, ISO 27001 or any equivalent third-party certification. We do not claim such certification.

In the event of a personal-data breach likely to result in a risk to your rights and freedoms, we will notify the Austrian Data Protection Authority within 72 hours of becoming aware of the breach (Art. 33 GDPR) and, where the risk is high, notify affected individuals without undue delay (Art. 34 GDPR).

13. Cookies and marketing-site analytics

On the Martez application — served on the domain at which you are reading this Privacy Policy (currently mrz.021-fast.fun, with app.martez.io planned as the canonical production domain) — we use only strictly necessary cookies for authentication, session management and security. No tracking cookies are set in the application.

On our marketing website (performromance.com and equivalent marketing domains) we operate our own self-hosted Matomo instance for first-party analytics. The Matomo tracking script and any associated non-essential cookies load only after you grant consent through our cookie banner (our consent-management mechanism). You can withdraw consent at any time by re-opening the cookie banner from the page footer; we will then stop loading the Matomo tag and clear any non-essential cookies it set on your device.

Matomo is also offered as a Customer-connectable in-app integration: a Customer may connect its own Matomo instance to a Martez Project in order to import its analytics data for attribution and reporting. In that role Matomo is processed as Customer Data under Section 5.2 and listed as a sub-processor in Section 8. The Customer's own Matomo instance is independent of the marketing-site instance described above; the two share only the underlying open-source software.

We do not use Google user data or Meta Platform Data in any cookie or marketing-site analytics tool.

13.1 Cookies set by the Martez application

All cookies set on the application are strictly necessary for authentication, session management and security; no tracking or analytics cookies are set on the application itself.

  • martez_session — first-party session cookie. Purpose: maintains your authenticated session in the Martez application. Duration: session lifetime configured per environment (typically 120 minutes of inactivity, refreshed on use); cleared on logout. Flags: Secure, HttpOnly.
  • XSRF-TOKEN — first-party CSRF token (set by Laravel's CSRF middleware). Purpose: protects form submissions and Livewire actions against cross-site request forgery. Duration: same lifetime as the session cookie. Flags: Secure.

No third-party cookies are set on the application.

13.2 Cookies set by the Martez marketing website

On the marketing website we use only consent-gated cookies. When you grant consent through the cookie banner, our self-hosted Matomo instance sets the following first-party cookies:

  • **_pk_id.*** — first-party Matomo visitor identifier. Purpose: distinguishes returning visitors for aggregate analytics. Duration: 13 months.
  • **_pk_ses.*** — first-party Matomo session cookie. Purpose: distinguishes the current visit for aggregate analytics. Duration: 30 minutes.
  • mtm_consent / mtm_consent_removed — first-party Matomo consent-state cookie. Purpose: remembers whether you have granted or withdrawn analytics consent so we do not re-prompt you on every page. Duration: 30 years.

No third-party cookies are set on the marketing website.

14. Children

Martez is a business-to-business product and is not directed at children. We do not knowingly collect personal data from individuals under the age of 14. Austrian DSG §4(4) sets the digital-consent age at 14. If you believe a child has provided personal data to us, please contact office@performromance.com and we will delete the data.

15. Changes to this policy

We may update this Privacy Policy from time to time. The "Effective date" at the top of the policy reflects the date of the most recent version. For material changes (for example, adding a new category of data, a new sub-processor that receives Google user data or Meta Platform Data, or a new processing purpose), we will notify account holders by email at the address associated with the account at least 14 days before the change takes effect.

Version 1.1 (effective 2026-05-22) introduces a dedicated Section 4 — Meta Platform Data and the Marketing API in connection with Meta App Review, tightens the disclosure of Google OAuth scopes in Section 3.2, and renumbers subsequent sections accordingly.

Version 1.2 (effective 2026-10-06) corrects the Google Ads scope classification, adds campaign delivery status to the Google data disclosure, and clarifies Facebook Login and user-initiated Meta pause/resume. It adds Cloudflare to the sub-processor and international-transfer disclosures and clarifies that Google user data and Meta Platform Data pass through CloudFront and Cloudflare in encrypted transit without being cached or stored there.

Previous versions of this policy are available on request.

16. Contact

For any question, request or complaint regarding this Privacy Policy or our processing of your personal data, contact us at:

Raphael Kagermeier (Performromance)
Neubaugasse 24, 8020 Graz, Austria
Email: office@performromance.com
Phone: +43 680 2200968