Adovo

Enterprise integration platform

SegmentSync: Reusable Audience Integrations

Teams could configure recurring audience and dataset movement with shared connections, mappings, schedules and run history.

The challenge

Every audience connection required another custom integration.

Business outcome

The product created a reusable way to configure, schedule and monitor audience movement.

Engagement context
Anonymized enterprise engagement
Operating flow
Configure once → schedule → monitor → reuse

01 / The problem

Each new audience connection demanded another custom build

Moving campaign and audience data between systems meant repeating mappings, schedules and recovery logic. That slowed new integrations and left each flow with its own support burden.

01BigQuery → Oracle EloquaMapping · schedule · retry · monitoring
02BigQuery → Adobe Experience PlatformMapping · schedule · retry · monitoring
03AEP → Oracle EloquaMapping · schedule · retry · monitoring
04REST API → destinationsThe same control logic repeated again

N × M pipelines repeated the same operating logic

02 / Solution

One reusable layer replaced custom builds

Connections, configuration, execution and operations came together as one reusable product platform.

01SourcesBigQuery · AEP · REST APIs · other sources
02SegmentSync coreConnections · schema discovery · audience builder · mapping · sync projects · scheduler · checkpoint state
03DestinationsOracle Eloqua · AEP · REST APIs

RabbitMQ · PHP workers · retries · run history + logs

03 / Business outcome

Teams could configure recurring data movement on a shared platform

Reusable connections, mappings and schedules gave each new sync a starting point. Run history, retries and checkpoints made interrupted work easier to diagnose and resume.

01One reusable layerConnections, mappings, schedules and execution patterns reused across projects
02Less manual movementAudiences and datasets moved on recurring schedules
03Operable by designCheckpoints, retries, status, history and logs made syncs recoverable and visible

Configure once. Schedule it. Monitor it. Reuse the integration.

04 / Execution architecture

Scheduled syncs ran through one execution layer

The scheduler loaded configuration and checkpoints, then queued concurrent work before destination execution and state updates.

01Source systemsGoogle BigQuery · AEP datasets · REST APIs
02Scheduler + projectLoad sync project · read checkpoint · enqueue jobs
03Queue + concurrent workRabbitMQ · worker pool · read · transform · map
04Destination + stateWrite records · success update · checkpoint · retry state

Run history and monitoring made broker work, retries, checkpoints and recovery visible

05 / Audience builder

Audience rules became a visual workflow

Teams could discover available fields, compose nested rules without writing SQL, save an audience and reuse it in scheduled syncs.

01Choose a source datasetDiscover available BigQuery or AEP fields
02Define rules visuallyFields · operators · nested groups
03Save the audienceCreate a reusable activation object
04Attach to scheduled syncsReuse the same definition in recurring projects

06 / Configurable activation

Mappings made every activation configurable

Each sync project could align different source and destination schemas without hard-coding a new pipeline.

01Source fieldsemail · audience_id · qualified_at
02MappingDirect · rename · date transform
03Destination fieldsEmailAddress · AudienceId · QualificationTimestamp

Configuration, not hard-coded pairs

07 / Reliable execution

Checkpointed execution kept recurring syncs recoverable

The platform read only what changed and advanced state only after successful destination processing.

01Read checkpointResume from known state
02Identify deltaNew or changed records
03Process concurrentlyMultiple PHP workers
04Destination writeMap + write records
05Commit checkpointAdvance only after success

Failure · retry / error state · run history · logs · checkpoint safety

08 / Operational evidence

Every sync exposed its operating health

Execution runs, event logs, project health and checkpoints made successful work, failures and recovery inspectable.

01Execution runsRun ID · status · schedule · duration · records loaded
02Run event logMessage receipt · lock · processing · completion
03Project healthSuccess rate · failures · retries · runtime
04Checkpoint stateThe safe point for the next run

The work presented in this case study was delivered by members of the Adovo team through Adovo and/or during previous enterprise engagements.

Continue exploring

Data & Analytics

dbtDeveloper Experience

dbt lineage browsing stalls when every focus change recompiles

Diagnose repeated background compilation in the dbt VS Code Lineage panel and protect the development workflow while a fix is pending.

Read more

Data & Analytics

dbtDatabricks

A Databricks materialized view breaks after an upstream column appears

Spot query-schema drift in dbt materialized views before a refresh failure surprises downstream users.

Read more

Data & Analytics

dbtDatabricks

A dbt Fusion null override can leave an inherited DELETE merge action

Audit effective dbt merge configuration before a model-level null override is trusted to remove a destructive action.

Read more
Explore data and analytics services →