Building a Scalable Overseas Ad Platform: Architecture, Permissions & Automation

Background

The company is expanding overseas projects, increasing demand for traffic placement and data dashboards, requiring a fast‑built overseas environment. While some domestic functions can be reused, differences in overseas business necessitate additional development.

Domestic user role granularity is insufficient; the overseas platform needs finer control.

Overseas data dashboards differ from domestic ones.

Product integration processes differ and must be re‑engineered.

Attribution callbacks differ and require a new service.

The work will cover overall system architecture, user permission module, product automation module, and AppsFlyer attribution module.

1. System Overall Framework

Core services for the overseas platform include management platform service, data ingestion service, new device service, attribution callback service, and offline task service.

Service relationships:

Management Platform Service: Front‑end and back‑end for product configuration, data reporting, ad account management, and batch ad creation.

Data Ingestion Service: Consumes Kafka events (activation, login, payment), determines new devices, and forwards data to the attribution service.

New Device Service: Uses device identifiers and a Redis activation pool to detect new devices.

Attribution Callback Service: Sends attribution data to AppsFlyer and other media pixels (Facebook, TikTok).

Offline Task Service: Pulls advertising data from media marketing APIs for dashboard reporting.

2. User Permission Control

The module must support two core requirements: fine‑grained role division per product, and automatic permission addition when new products are added to a project group.

We introduce a hierarchy of team → project group → product (see diagram).

Permission information is stored in a project‑group member permission table; a user can hold multiple roles across multiple project groups. The has_all_app flag indicates whether the user has permissions for all products in the group, enabling automatic permission grant for newly added products.

We chose a write‑propagation strategy: when a new product is added, the user’s app_id_list is updated in bulk, avoiding costly read‑expansion queries.

3. Product Automated Onboarding

Automation aims to streamline new product integration with three main functions:

Product metadata sync: overseas platform periodically pulls product info from the domestic CHL platform.

Data source integration: automatic Kafka configuration for AppsFlyer SDK, real‑time tasks for user and finance middle‑ends.

Dashboard dependencies: automatic creation of base CK tables, datasets, and dashboard tasks.

Product Integration Flowchart:

The backend displays product onboarding status (see diagram).

Onboarding steps:

After SDK integration, configure Kafka in appsfyler_kafka_config and start the activation pool service.

Check middle‑end status; if integrated, trigger user‑center and finance‑center data tasks.

Trigger offline traffic tasks.

Trigger base CK table creation tasks.

Trigger dataset creation tasks (real‑time and offline).

Trigger asynchronous dashboard tasks and poll until completion, then store report IDs.

Execution Flowchart:

4. Batch Ad Creation

The platform integrates media marketing APIs to enable batch ad creation, illustrated below.

Workflow:

Select the target application.

Choose one or multiple ad accounts.

Select an ad template (media‑required settings).

Select the target audience.

Choose copy (multiple options allowed).

Choose creative assets; the system combines copy and assets to generate multiple ad creatives.

Submit to launch; the backend creates ads via media APIs and displays results in the campaign management page.

Ad Template Diagram:

5. Attribution Data Return

Overseas attribution differs: instead of direct media integration, we rely on AppsFlyer. The new server‑side flow simplifies client SDKs and centralizes control.

Steps:

App launch triggers AppsFlyer SDK to report activation to the tracking service, which pushes to Kafka.

If integrated, user‑center and finance‑center SDKs report login/payment events directly to middle‑end services (log format).

Middle‑end services forward events with appsflyer_id to the big‑data Kafka.

Big‑data consumers push new activations to a Redis activation pool.

Data warehouse consumes Kafka to generate activation, login, and payment reports.

Traffic service consumes Kafka, extracts ad info, stores it, and forwards events to the attribution service.

Attribution service decides whether to callback; if so, it sends events to AppsFlyer.

System Interaction Diagram:

Advantages over client‑side callbacks:

Simplified client SDKs; only event logging required.

More flexible integration choices.

Server‑side callbacks are more controllable, monitorable, and fault‑tolerant.

Consistent attribution definitions without client releases.

Reduced infrastructure cost by limiting deployment to a single cluster.

Optimizations such as deduplication and delayed queues are possible.

Future Plans

Support batch creation for more media (currently Facebook; TikTok in progress; Google, Kwai upcoming).

Explore automated budgeting strategies based on performance metrics and eventually manage the full ad lifecycle.