Affiliate

In short

Two menu items: Overview (results) and Settings (program rules).

What it does

Where to find it in the app: Sales → Affiliate

• Tracks partners, their links, commissions and payouts.
• Settings is a separate screen, not a tab inside the overview.

How to set it up

Step-by-step instructions are being written. For now this page states where the feature lives in the app and what it covers.

Partner portal and appearance

Partners sign in and register on the public portal — at the fallback address …/partner/<store code> or on your own domain (the Domain tab). At the top is a band in the programme’s primary colour with the sign-in (or registration) card and, next to it, the contact person card — the Affiliate manager with photo, phone and e-mail. The optional programme description sits below; on a phone everything stacks.

It is configured in Settings → Programme & appearance: Programme (name, registration mode, auto-approval of partner sign-ups — conversion approval is a campaign setting, see below), Contact person (name, e-mail, phone, profile photo URL — without a name and e-mail the card is not shown), Portal appearance (logo, colours, privacy policy link) and Registration and partner data (which fields are required when). The logo has a single source — the portal uses the logo set for your account (Settings → E-mails → Logo); text colour on your chosen colour is computed to stay readable.

At registration the partner ticks a single box: “I agree to the Programme Terms and acknowledge the Personal Data Processing Information” — both names are links that open the wording in a new tab. The privacy notice is not a consent to processing (processing rests on the contract and the law), so it is not asked separately; the audit records acceptance of the terms and acknowledgement of the notice, each with a fingerprint of the wording. The partner also confirms the documents you marked as required at registration (the Documents tab). The document name opens the PDF in a new tab, next to it is Download; a document without uploaded wording is not shown to partners.

Both the terms and the privacy notice are built-in documents in the Documents tab: a new programme gets them pre-filled in all languages with your data from Settings → Account. They are editable templates — MitoOps does not guarantee their legal accuracy; compliance with the law in your country is the programme operator’s responsibility. They cannot be deleted or disabled, only their wording changes.

One partner, stores one by one

A partner is one account for your whole client account (one login, one public code), but the programme runs per store. Which stores the partner sees is decided by membership: registering through a store portal (…/partner/sk) grants access to that store only — its campaigns, the partner code is created there and only that store’s documents apply (readiness never asks for other stores’ contracts). You enable or revoke further stores in the partner detail, section Partner stores; the partner can request a store from the portal (Campaigns → Your stores) — you get an e-mail and decide, nothing switches on by itself. Registering the same e-mail through another store’s portal does not create a second account; it is recorded as a request for access to that store — the partner gets an e-mail about it and you handle it just like a request from the portal (nothing is granted automatically and no account details change). Revoking a store keeps history (conversions, coupons); the store’s campaigns disappear for the partner and their code there is ended per programme settings, re-enabling brings it back. Partners from before membership existed had it derived from their registration store, coupon and conversion stores and explicitly assigned campaigns; a partner without such data got all connected stores.

Store access request together with a code. The Request access button in the portal only opens a panel next to the store: the partner writes a note (up to 500 characters), chooses whether to carry over their existing code, propose a new one or go without a code, and only then clicks Send request. In the partner detail (section Stores and codes) you decide in one step: Approve access and code, Approve access only or Reject with a reason. The code is created in the store with that store’s campaign discount; if the campaign has no discount, access is granted and the row says “blocked” with a link to the campaign — after you set the discount, just Retry. The partner receives an e-mail with the outcome.

A partner code has a history. One canonical code is carried over to further stores (also in bulk by ticking stores); an existing store coupon — for example a code the partner used long before the programme — can be adopted without creating a second one: you type it, MitoOps finds it among the loaded coupons, shows discount, validity and usage and compares the discount with the campaign discount (if they differ you confirm you are adopting it with the original discount; the discount in the store is not changed). A code that has already brought orders is never deleted — you retire it (valid until yesterday) or replace it with a new one, and the old one is retired only after the new one succeeds. Orders with the old code stay the partner’s; the partner sees retired codes and which code replaced them.

Registered websites and the payout document

The partner detail has two things you decide on: registered websites (the partner lists where they promote you; they arrive as Waiting for approval and you Approve or Reject them with a reason the partner sees — approval sends them an e-mail) and payout documents (the basis for paying a commission: an invoice from a partner with a company ID, covering a specific period, or a brokerage agreement from one without, valid until revoked). The file is uploaded by the partner in the portal or by you with Add document. If a partner without a company ID has a signed programme agreement, that is the basis for the payout and no further document is needed — the tab says so and the payout goes through. A document is never deleted, only voided. The payout flow is always the same: the partner requests a payout, you approve the batch and pay it out.

Partner code: commission is not the discount

A campaign has two independent values: the partner commission and the customer discount on the partner code; neither is derived from the other, and the partner sees both named on the Campaigns tab next to the attribution window and approval mode. An approved code is created in the partner’s stores whose campaign has a customer discount; without it the creation is Blocked — the Discount codes tab shows the store and campaign with a link straight into it, and after setting the discount Retry creation finishes it. Nothing is created twice and the partner meanwhile sees “being prepared”, never a false “active”.

Partner link applies their code automatically appends the code with the mitoops_coupon parameter — the same mechanism as coupons in Emailing, applied by the MitoOps web code; the parameter name is not configurable. If a store has no web code able to apply a coupon from the URL, the setting warns you: the link carries the code, but the discount does not apply itself in the cart (attribution still works, it rests on the click identifier). Click validity (attribution window, e.g. 30 days) and Click record retention (e.g. 180 days) are two settings: one says how long an order is still attributed after a click, the other how long the click stays in analytics.

Portal texts and variables

The texts a partner reads live in four places: Portal pages (Sign-in, Registration, After sign-in — three system pages with a preview and an editor that says where the text is shown), Programme description (Texts tab), Campaign description (per campaign; without your own text the partner gets a default one with the campaign’s values) and Articles (Articles tab; partners read them in the Help section). All have default text in eleven languages that you can rewrite or restore.

Texts may use variables filled from settings so a number never drifts from the campaign: for example {{provizia}}, {{atribucia_dni}} and {{schvalenie}} (in a campaign), {{minimum_vyplaty}}, {{zaklad_provizie}}, {{program}}, {{prevadzkovatel}}, {{meno}} and {{kod}} (after sign-in) and section links ({{odkaz_vyplaty}}). The editor offers only variables that have a value in that place — for each one you see the token, its name, an “i” bubble with the explanation and an example (works with mouse, keyboard and touch) and a Copy button. The token (for example {{prevadzkovatel_email}}) is the same in every application language; only the name and explanation are translated. Campaign variables ({{provizia}}, {{schvalenie}}…) are not offered for insertion in the programme description: they are filled there only when the store has exactly one public campaign, otherwise they belong in the campaign description where the rate is unambiguous — the bubble says so. A variable without a value is not shown to the partner; a {{#minimum_vyplaty}}…{{/minimum_vyplaty}} block appears only when a minimum exists. A campaign with manual approval has no {{schvalenie_dni}} — the text never lies.

The same variables work in e-mails, with aliases from older templates ({{partnerName}} equals {{meno}}, {{amount}} equals {{suma}}); the full registry with type, surfaces and aliases comes from affiliate_variables_list. Wording drafts: a new wording of the terms, the privacy notice or your own agreement may arrive as a draft — from the app or a connected assistant (MCP). Partners do not see it and nothing changes until you publish it on the Documents tab, where you see the diff against the current text; publishing creates a new version with an audit trail (who, when, hash). Partner acceptances stay bound to the wording they saw; with “re-confirm on a new version” enabled, partners confirm again.

The portal preview (Show preview) opens the real portal with a fictitious partner and numbers; every section can be clicked through and nothing is sent. After sign-in the partner sees a Have a question? panel on the right with the contact person — the same one as on the public page.

Partner links on your own domain

Until a store has its own domain, partners receive links in the form https://<application address>/api/r/<partner code>?k=<campaign>. As soon as the store’s own domain is connected and active, links are composed on it automatically — in the portal, in e-mails, in the sub-page link generator and via the API. The form is https://affiliate.yourdomain.com/api/r/<partner code>?k=<campaign>, and where the platform operator has also set up the short path for the domain, https://affiliate.yourdomain.com/r/<partner code>?k=<campaign>. Both work and measure identically; the short one is merely shorter. The Domain tab shows for each store the exact form partners receive. Links partners already shared via the application address keep working; after deactivating the domain new links fall back to the application address. A link is bound to the domain’s store: a link with another store’s campaign is not honoured on it. <partner code> is the partner’s public code (their account); k is the campaign number that sets the destination and commission terms.

Main domain and aliases. A store can have several verified domains at once — typically when moving from a temporary to a final address. New links and e-mail addresses are generated from the main domain; the other active domains are aliases: links partners have already shared keep working through them, new ones are not generated from them. To move: add the new domain with Add another domain, write the DNS records, click Verify and connect and then Set as main; the old domain stays an alias until you deliberately delete or deactivate it. The portal address in e-mails uses a domain under the same conditions as links: connected (DNS and certificate) and activated.

Visits from partner links in Google Analytics. Besides the click identifier, the redirect adds tags for the store’s analytics to the target address: utm_source=affiliate, utm_medium=affiliate, utm_campaign=mitoops-<store code>-k<campaign number> (for example mitoops-de-k5) and utm_content=<partner code>. Google Analytics 4 then files the visit under the Affiliates channel instead of direct traffic (direct) / (none), even when the link was opened from an app or an e-mail that does not send the referring page. Tags already present in the campaign’s target address or in the partner’s subpage are not overwritten. The exception is the medium, which is always affiliate for a partner link. Attributing the order to the partner does not depend on these tags; it relies on the click identifier.

Visitor consent to storing the click

A click is always counted — it is recorded on the server during the redirect and nothing is stored in the browser. So that an order from the link can be attributed later, the website code stores the click identifier in the browser, and only with the visitor’s consent. It checks consent in this order, and the first source with an answer decides:

1. Your own shop integration — if the page defines window.mitoopsSuhlas, the code asks it (window.mitoopsSuhlas('meranie') returns true or false). This lets you connect any consent tool MitoOps does not know.
2. The shop platform’s consent — on Shoptet its consent bar, on WooCommerce the WordPress Consent API.
3. TCF (the consent-management standard) — purpose 1.
4. Google Consent Mode — analytics_storage.
5. If consent cannot be determined at all, the identifier is stored.

While consent is missing the click is not stored, but it is not lost either: if the visitor consents later on the same page, it is added. Withdrawn consent deletes the stored identifier. Attribution through a discount code does not depend on consent — the code is part of the order.

The shop’s own measurement (its tags, server-side Google Tag Manager, analytics) is not affected: the website code only reads Consent Mode and the dataLayer, never writes to them and never calls anything.

Electronic signature of agreements

For each programme document you choose a confirmation mode: acknowledgement (the partner ticks that they have read it), electronic signature in the portal, or uploaded signed copy (the partner prints, signs and uploads; you review it). With the electronic signature the partner reads the exact wording with the values filled in (your company and signatory, their details, the store and the campaign terms), types their name, confirms they are signing and clicks Sign electronically — a drawn signature with the mouse or a finger is optional. An immutable record is stored: the signed wording, its hash, time, name, method and identity verification. The signed PDF can be downloaded any time by the partner and by you; it is generated from the record, not from the current document, so later changes to the template, campaign or company details never alter it.

Signing at registration goes through e-mail: the partner receives a link (valid 24 hours, single use) that confirms their address and opens the signature — before the account is approved. The registration form does not tick such a document, it only announces it. A signed-in partner signs in Documents; when you publish a new version with “re-confirm on new version”, they see New version to sign and sign it separately — the original signature is kept. An account taken over by an admin (“Sign in as”) cannot sign.

The Signed agreements tab lists all signatures (filters by partner, document, store, state and period), a detail with the exact wording and evidence, PDF, CSV export and partners with a missing signature — you can send them a signing request by e-mail. A signature cannot be edited; an admin may revoke it with a mandatory reason (the record remains as revoked). A partner with a signed agreement cannot be deleted, only rejected or have their personal data erased.

A built-in partnership agreement template is ready in every programme language for every account — disabled until you enable it under Documents. The wording is neutral: the operator, the partner (company or individual), the store and the campaign terms are variables filled in at signing. Enabling it requires an operator signatory in Settings → Programme (who concludes agreements on your behalf). Edit the template through a wording draft; “New agreement from template” creates another wording, e.g. for one store. The template is not legal advice — adapt it to the law that applies to your programme before enabling it. The electronic signature in MitoOps is an electronic expression of will with an audit trail, not a qualified electronic signature under eIDAS.

Parties in the PDF. Under the signature lines the operator appears as the legal entity from the account’s billing profile (Settings → Account) with company ID, signatory and role (Settings → Programme) — the programme name is in the document header as a programme name, not as a party. The partner appears as a company with company ID, signatory and role, or as an individual by name. The values come from the snapshot taken at signing, so a later profile change does not alter old agreements.

Adopted coupon carries a marker in the store. When you assign an existing store coupon to a partner (or replace an old one with it), the application appends the marker “MitoOps Affiliate · partner … · campaign …” to the coupon note in the store administration. The merchant’s original note stays, the marker is never duplicated and the coupon discount is not changed. If the store rejects the write, the code assignment stands and the application only tells you.

Operator stamp and signature. The stamp image is one for the whole app: upload it in Claims → Email templates | Documents or in Affiliate → Settings → Documents (both blocks show the same file). The signed agreement gets it in the “Signatures of the parties” block above the operator’s signature line together with the representative and role; next to it is the partner’s signature with the time. The stamp is always bounded and never breaks the document.

Overview and statistics: what the numbers mean

Overview and Statistics (admin and partner) are computed from one source, so the partner sees the same number for the same period as you do. Filters: period, store, campaign, partner. Clicks are valid redirects through the partner link without bots and without repeats from the same address within a short window; unique means distinct addresses. Clicks do not depend on the visitor’s storage consent — consent only decides whether an order is attributed from the link. Conversions are attributed orders excluding rejected and cancelled ones; rate is conversions / clicks. Money is always per currency. Funnel: clicks → conversions → approved → paid; sources: tracked link, discount code, manual. Days are counted in UTC.

Two settings that get confused: Click validity – attribution window is how long after a click an order is still attributed to the partner; Click record retention is how long a click stays in statistics (180 days by default; a click backing a commission is never deleted).

The filter also has discount code, attribution source and conversion state and a table by discount codes (a retired code stays in it). With a code filter, clicks are 0 — a click carries no code. In the Overview the partner also sees Commission base for the period and Commission for the period and in Statistics filters only by their own codes. An order attributed to a partner by link also appears in Analytics (channels, order list) as “Affiliate · partner”, not “Unattributed”; a cancelled conversion is not attributed.

Team notifications: a new registration, a store, code or website request, a payout request and a signed agreement arrive in the bell and — depending on topic, role and the Affiliate permission — as a push to the phone, with a link straight to the place in the app. Registration has an optional About me field (500 characters) that you see at the pending registration, in the detail and in the e-mail.

Conversions and commission: two amounts, two names

The commission base is the amount the commission is calculated from according to the programme settings (goods excluding or including VAT; shipping and the payment fee are excluded by default). The order total incl. VAT is what the customer actually paid. An example from a real order: goods 89.55 + 5.31 incl. VAT (23 % VAT), free shipping, 10 % commission — base 77.12 (excl. VAT), order total incl. VAT 94.86, commission 7.71. Both amounts appear in Conversions, in the CSV, in the partner e-mail ({{revenue}} is the base, {{orderTotal}} the total incl. VAT) and in the partner portal; the amounts are stored from the order, nothing is estimated.

The Affiliate → Conversions tab is the working screen for approvals: filters by partner, store, period, commission state, source, order number and order classification; every conversion shows the order status from the store (the same as in Orders → Overview) classified as open / completed / cancelled. The classification is context, not a decision — cancellations and credit notes change the commission by the programme rules. Rejection and cancellation ask for a reason the partner receives by e-mail; bulk approval has a confirmation with the count. The CSV export carries the same filter, the order status and unambiguous columns; the partner’s CSV has no order status and no customer data.

Automatic conversion approval

Conversions can approve themselves, and it is configured on the campaign, not in the programme settings: Affiliate → Campaigns → campaign → Conversion approval with the options Manually (default) and Automatically (once conditions are met). With automatic approval the campaign conditions appear:

• Approve no earlier than (days after the order) — the return period, default 14. Days count from the order creation (not from delivery: the store does not send us a status history, so “days since delivery” would be a guess).
• Approve only in order statuses — you pick from the real statuses of the campaign’s store (the Campaign store field; for example Delivered, Completed), the same ones as in Orders → Overview and in Automations. A campaign belongs to one store and that never changes; in New campaign you pick one or more connected stores and a separate campaign with identical settings is created for each — a campaign for another store has its own statuses. Empty = any status. An order whose status the application does not know (for example a manually added conversion without an order in the mirror) is never approved while the list is filled in.
• Require a paid order — default No, because cash on delivery is paid on pickup. With Yes only an order whose payment state is paid (Shoptet paid flag, WooCommerce payment state) is approved; an order with an unknown payment state is not.

A conversion is approved only once every selected condition is met. Once an hour the application goes through new conversions of campaigns with automatic approval; the partner receives the same e-mail as with a manual approval and the audit records “system” as the decision maker. A conversion that does not meet the conditions yet keeps waiting — next to its state in the Conversions tab you can see what the automation is waiting for (for example “waiting for the holding period (3 d)” or “the order is not paid”). Partners see the period in the campaign description through the {{schvalenie}} variable.

What always applies, regardless of the settings:

• An order cancellation rejects the conversion (an approved one is cancelled) and a credit note reduces it or, when the whole order is returned, cancels it — with manual and automatic approval alike. The automation never approves a cancelled order or a fully returned one, even if every other condition matches; a partially returned order is approved with a reduced commission.
• A paid-out commission is never touched by the system — it is settled with the partner.
• The setting applies per campaign: every campaign belongs to one store and has its own mode, period and statuses.
• Existing campaigns did not change when the conditions were added: a campaign that had “automatically after the period” keeps approving by the period alone until you add conditions.

If you need a condition the campaign does not have (a minimum value, a specific partner), keep Manually and decide in the Conversions tab, where every conversion shows the order status and payment state.

Frequently asked: How do I reject a conversion? In the Conversions tab click Reject next to a new conversion and enter a reason — the partner receives it by e-mail; an approved conversion can be Cancelled, a paid-out one cannot. Can I approve only completed or delivered orders? Yes — pick the statuses in Approve only in order statuses on the campaign. Does MitoOps check whether the order is paid? Yes, it takes the payment state from the store and shows it next to the conversion; it only affects automatic approval when Require a paid order is on. What happens on cancellation or refund? Cancellation rejects or cancels the conversion, a credit note reduces it or cancels it when the whole order is returned — automatically, with both approval modes.

API and MCP

With the affiliate:read scope your program or an AI assistant reads the overview, partners, campaigns, codes, conversions, payouts, settings, documents, portal status, e-mail templates, help articles and code requests. It also reads legal document wording per language with hashes (affiliate_documents_get; partners’ electronic signatures read-only via affiliate_signatures_list and affiliate_signatures_get) and the variable registry (affiliate_variables_list). With the sensitive affiliate:write scope (MCP only) it may approve, reject or suspend a partner account, enable or revoke a partner’s store (affiliate_partners_set_market), handle a code request, update non-financial settings, portal texts, help articles (create, edit, restore the default wording, enable or disable; never delete), templates, campaigns and document policy. New legal wording (including the privacy notice) is saved only as a draft (affiliate_documents_draft_create) — you publish the live wording in the app. Conversions (affiliate_conversions_list, detail affiliate_conversions_get) carry the commission base and the order total incl. VAT, the state reason and the order status from the store with an orderState filter. Automatic approval is read and set on the campaign through the interface: affiliate_campaigns_get returns approval (manual / automatic), approveAfterDays, requiredOrderStatusIds and paidRequired; affiliate_campaigns_update changes them with the affiliate:write scope (status identifiers must be statuses of the campaign’s store). Every conversion in the list and in the detail carries approvalPolicy (its campaign’s policy) and approvalEligibility — whether the automation would approve it right now and why not (minimum_age_not_reached, order_state_not_allowed, order_not_paid, order_cancelled, fully_refunded, approval_manual, …); it is the very calculation that runs every hour, not a second copy. The list has the filters orderPaid, minCommission, orderState, state, a period and paging (offset, hasMore), so an assistant can “go through new conversions of the last two months, show the unpaid ones or those above €20” and then call affiliate_conversions_decide for every named conversion separately. The in-app assistant explains and reads the same, but changes nothing. Commission decisions have their own sensitive scope affiliate:approve (MCP only): the assistant may approve, reject or cancel one specific conversion you name (rejection and cancellation with a reason, a paid commission is never reverted), through the same path as in the app. There is no bulk approval in a single call. Payouts are read-only through the interface (affiliate_payouts_list): creating a batch, its document, sending it to the partner or a bank order cannot be triggered through the API or MCP — they stay in the app. Details in the MCP interface.

Related

• Discount codes
• MCP interface