Let’s take one day in an affiliate program with a hundred webmasters. In the morning, the manager sends new links to partners because the offer for Spain was changed yesterday. At the same time, the finance manager exports conversions to Excel and manually separates CPA from RevShare to close the account for a top partner. The analyst builds a third identical widget, just for another GEO. The integrator goes into the admin panel to create product goals because they cannot be created through the API.
Each action takes minutes, none of them looks like a problem, and none of them appears in a work report.
From March to September, Alanbase released 35 updates, and almost all of them address this exact workflow. Below, they are grouped not by release date, but into six areas: where traffic goes, how money is calculated, how statistics are analyzed, how partner management works, where team tasks live, and what can be done through the API.
Each feature is covered in detail with a configuration demonstration on our YouTube channel.
Routing: One Link for the Partner, All the Logic on Your Side
The most noticeable theme of the past six months. Previously, traffic routing lived in partners’ notes: one offer for each country, one link for each offer, and every change to the setup meant spending someone else’s time.
With a hundred partners, updating a link could take a week, and throughout that week some traffic would go to places where it was no longer being paid for.
Smart Link. A separate platform section where a country is linked to an offer: Germany to Offer A, France to Offer B, Spain to Offer C. The partner takes one tracking link from their account and never has to return to this issue. When clicked, the system identifies the country, checks the partner’s access to the offer, and sends the traffic there. The click is recorded against the offer to which the redirect occurred. The setup can be changed tomorrow while the webmaster’s link remains the same. Available as part of the plan or as a separate option upon request.
Landing page in targeting rules. A targeting rule now distributes traffic within an offer based on country, device, partner, and sub-parameters. Previously, the end of the rule contained a bare URL, and the platform did not know which landing page was behind it. Now, instead of a URL, you select an offer landing page. The click records which landing page was used, allowing you to compare landing pages within the same offer in statistics. A landing page used in at least one rule cannot be edited or deleted, preventing a colleague from accidentally removing a page receiving half of the traffic.
Traffic sources as an entity. An administrator creates sources in the settings, specifies which are allowed or required in an offer, and the partner selects their source when generating a link. The parameter is inserted automatically. Statistics now include a filter, grouping option, and “Traffic Source” column. The question of “which channel brings conversions and which only consumes budget” can now be answered without third-party tools.
Landing page open to everyone except a list. Imagine a network with 3,000 partners and a new landing page that two of them should not see. Previously, the solution was essentially backwards: make the landing page private and manually grant access to thousands of people. Now there is an exclusion mode: the landing page is available to everyone, while unwanted partners are added to an exclusion list when creating or editing the page. Minutes instead of hours.
What this delivers together: traffic routing is completely under your control. The partner keeps one link while you change offers, landing pages, and traffic sources without sending them a single message.
Payments: More Precise Conditions, Cleaner Models
Hybrid models have long been standard: a serious affiliate program works with partners on CPA and RevShare simultaneously, sometimes adding a Fix Fee.
While the volume is small, payments can be entered manually. At scale, manual reconciliation creates financial errors, and one disputed payment to a top partner can damage trust more than a week-long delay in a manager’s response.
Fixed payments in the interface. Previously, fix fees and prepayments required an API or separate accounting outside the CPA model. Now, a fixed payment can be created directly in conversions: partner, offer, date, revenue, payment, and status. It is accounted for separately and visible in overall statistics. Placements, integrations, and performance are now calculated within one system.
Invoices by payment model. Previously, when creating a payment, the system pulled in all eligible conversions, even when only RevShare needed to be closed. Now, the payment creation window includes a “Payment Model” filter: All, CPA, RevShare, plus Fix Fee and CPM if enabled. A partner working on CPA + RevShare receives two correct invoices without duplicate offers or exports.
Special conditions by landing page and referral link. A payment can now be assigned not to an entire offer, but to a specific landing page or individual partner link: a higher rate for a “hot” source, a lower rate for a weak landing page, or different rates for creative testing. Link-specific conditions work in the individual settings of a single partner.
One special payment across multiple landing pages. This continues the previous feature. The limitation of “one condition = one landing page” has been removed. Within one payment, you can select the required landing pages, including through search when there are thousands of them. It works with “Goal,” “Formula,” and “Qualification” conditions, both globally and individually. Set one rate for a group of landing pages once and edit it once.
Displayed payment in RevShare. The calculated percentage and the percentage shown to the partner often differ: an advertiser pays the network 50%, while the network gives the partner 40%. Previously, you had to enter a workaround figure of 80% and break the logic. Now, the “Display to partner as” field separates the calculated percentage from the displayed percentage. Available in global, individual, and special conditions.
The result of this area: the partner sees the correct amount according to clear logic and receives it faster. For a program working with major buyers, this supports retention.
Analytics: Breakdowns Instead of Averages
The cheaper it is to build comparisons, the more often the team looks at detailed breakdowns.
Six months ago, analytics had three limitations: only three levels of nesting, no webmaster filter, and some metrics had to be calculated externally.
Up to five grouping levels and a WebID filter. Traffic can now be broken down across five parameters at once, while data for a specific webmaster can be isolated with a single filter in overall statistics and cohort analysis. Inefficient combinations can be identified without exporting data.
Qualifications in the formula builder. Custom columns previously lacked the number of qualifications, so reports had to be calculated in Excel or BI. There is now a “Number of Qualifications” variable with statuses: confirmed, on hold, pending, and rejected. The percentage of rejected qualifications for each partner is calculated directly in the table, and the numbers in the report match the numbers in the system because they are the same numbers.
Filters by referral link and payment amount. In conversion and event statistics, you can check a specific combination or display only paid conversions.
Date picker without opening filters. The period can be changed by clicking the active date range. Presets include today, yesterday, current week and month, last 7/14/30 days, and six months. The maximum statistics range has increased to 185 days.
Dashboard widget duplication. Need the same widget for another GEO or offer? Copy it with all settings and change one parameter before saving. A comparison dashboard can be assembled in a minute.
Data in the interface and exports match. The partner conversion export now includes the webmaster_id field, eliminating discrepancies when reconciling with partners and BI. The partner list can be exported directly to XLSX without manually processing CSV files.
{useragent} macro in partner postbacks. Partners receive the user’s user-agent directly, enabling device and browser analysis and providing additional anti-fraud signals.
Administrators in statistics schemes. Previously, all administrators automatically received access to additional tables. Now, specific people can be assigned to each scheme, keeping sensitive data restricted and separating analytics between departments.
The result: six months of analysis across five levels of depth can be done inside the platform rather than in an export.
Partners and Fraud: Qualification Before Approval
Multi-accounting and low-quality traffic from local affiliates remain major headaches in iGaming.
The second problem is quieter: when there is a large flow of applications and accounts, partner context becomes scattered across Telegram, spreadsheets, and CRM systems.
“Trusted Partner” and multi-account control. Verified partners can be manually marked as trusted. They are excluded from anti-fraud checks and visually highlighted. At the same time, the system automatically detects duplicate postbacks, marks the account, and notifies the administrator. Time is spent on suspicious accounts rather than top partners.
Mandatory question during registration. An administrator can add one question directly to the registration page. Without answering it, the partner cannot complete registration. The answer is stored in a separate field in the partner profile rather than among the other profile data. Partner qualification therefore happens before approval, not afterward.
Comments in the partner profile. Agreements, changes to conditions, and communication history are stored inside the platform and visible to all administrators with access to that partner. Onboarding a new employee no longer means digging through chats.
Full Name instead of a wall of emails. The field is mandatory for partners and advertisers, and accounts are displayed as (id) Full Name. For existing users, the field is automatically populated from the email address.
Tags for advertisers. Advertisers can be grouped by vertical, status, GEO, or any custom characteristic, with tags assigned in two clicks from the profile.
Hiding the referral program. A toggle removes the referral link from the partner’s profile and the “Referrals” item from the account menu, while the administrator can still see the link. Useful for projects where referral functionality is not needed by everyone.
The result: fraud is filtered at the entry point, while the full context for each partner remains in their profile.
Team Tasks: Task Tracker Inside the Platform
Tasks related to partners and offers previously lived in Jira, Notion, or spreadsheets, separately from the platform. Switching between systems created lost context.
Task tracker with Kanban board. A task includes a name, status, assignee (one or multiple), auditor, deadline, and description. Tasks can be linked to platform objects: offer, partner, advertiser, administrator, and invoice. Columns can be customized with your own statuses, names, and colors.
Filters. Filter by creation and completion dates, creator, assignee, auditor, partner, offer, product, and managers. All open tasks for a specific partner can be displayed in seconds, while bulk actions apply only to the filtered selection.
Drag-and-drop. Cards can be moved between columns and within a column without opening them for editing. The order is preserved after refreshing the page. Priorities can be changed with a single gesture.
The result: affiliate-program operations are managed in the same system where partners and offers live.
API and Integrations: Fewer Manual Steps Between Your Systems and the Platform
This is the longest area of the six-month update, and that is not accidental. Each method addresses a specific manual step that someone previously had to perform in the admin panel after the client’s service had already completed its work.
Entity creation. New methods include Create Admin, Create Advertiser, and Create Partner Postback, as well as Create Goal for product goals. Previously, all of these had to be created through the interface. A new is_active parameter has also been added to Create Product: if passed, the product is created as active; if not, the previous behavior remains unchanged, so existing integrations are not broken.
Landing pages through API. A complete set of methods is now available: retrieve a landing page by ID, create one for an offer or product, update its name, target URL, preview, access permissions, active dates and status, delete it, and retrieve a list. Campaigns can be scaled without manually creating landing pages.
Traffic sources through API. This includes a list of sources for administrators and partners, creation of new sources, and the allowed_external_traffic_sources parameter when creating or editing an offer. The primary source with ID 0 is always present in an offer. If the parameter is not provided, or a list is provided without zero, the platform adds it automatically.
Data sent externally. Partner List and Partner by ID now return an array of referrals with ID, email, and creation date. A new method returns partner tags. Another returns advertiser postbacks by events and goals, while preserving access permissions. The configuration can therefore be verified by request before it affects live traffic.
Proxied flag for tracking domains. A “Proxy Used” switch has been added to the domain form, while the domain list displays a Proxied label. In the Admin API, this is represented by the is_use_proxy field. It is mandatory when creating a domain and optional when editing one. The entire domain portfolio can be viewed from one screen.
Postback log filters. Useful for investigating incidents: multi-select filters by partner, offer, and advertiser. If a partner reports missing conversions across three offers, select the partner and offers to see all records and delivery statuses. Minutes instead of reviewing the entire log.
All methods are described in the current version of the API documentation.
What Connects All 35 Updates
Across all six areas, one principle runs through everything: the affiliate program grows, but the amount of manual work required to support it should not grow.
One link for ten GEOs. One invoice for one payment model. One filter instead of an export. One registration question instead of manually reviewing a profile. One API request instead of opening the admin panel.
Individually, most of these updates are not big enough to qualify as a major release. Together, they eliminate the kind of work that consumes team hours but never appears in reports.
New partners, GEOs, and traffic volumes no longer require a proportionate increase in headcount.
Want to see how this fits into your setup? Register for a demo call: Alanbase will gather your requirements, show you the platform configured around your offers and vertical, and set up a dashboard preset.
After the demo, get 14 days free, with no card required.
