How to Build Cross-Platform Ad Targeting (Lookup, Mapping, and Campaign Creation)

March 25, 2026

Cross-platform ad targeting means defining who sees your ads across multiple advertising integrations using a consistent approach.

In practice, this is one of the hardest problems in advertising systems.

Each integration uses different identifiers, different structures, and different validation rules. You cannot reuse targeting logic across integrations without building custom mapping layers.

This guide shows how to:

• look up valid targeting identifiers
• map targeting into a consistent structure
• apply targeting when creating campaigns and groups
• handle provider differences safely

Using the Unified Advertising API.

Why Ad Targeting Breaks Across Integrations

Targeting is not standardized.

Across integrations:

• Location IDs differ
  • Google uses geoTargetConstants
  • Meta uses location IDs
  • TikTok uses category IDs
• Audience definitions differ
  • interests, behaviors, custom audiences all vary
• Supported targeting types vary
• Validation rules vary

This creates a common failure mode:

You can build campaign creation for one integration, but not for many.

The problem is not campaign creation.

The problem is identifier lookup and mapping.

How Targeting Works in Advertising APIs

Targeting is not applied at the same level everywhere.

Object structure

Key rule

• Targeting is readable on campaigns
• Targeting is configured primarily at the group level
• Campaign-level targeting is only supported by some integrations

This distinction matters when building a product.

Step 1: Look Up Targeting IDs

Before you can define targeting, you need valid identifiers.

Unified provides a lookup endpoint:

const targets = await sdk.ads.listAdsTargets({
  connectionId,
  type: 'countries',
  query: 'united',
  limit: 50,
});

Target object

type AdsTarget = {
  id: string;
  name?: string;
  value: string;
  type?:
    | 'interests'
    | 'behaviors'
    | 'locales'
    | 'countries'
    | 'regions'
    | 'cities'
    | 'zips'
    | 'us_dmas'
    | 'topics'
    | 'user_lists'
    | 'age_ranges'
    | 'genders';
}

Important

• Use id when building targeting payloads
• name is for readability
• value reflects the provider-specific identifier

Supported Targeting Types

The lookup endpoint supports:

• Geographic
  • countries, regions, cities, zips, us_dmas
• Demographic
  • age_ranges, genders
• Audience
  • interests, behaviors, topics, user_lists
• Language
  • locales

Support varies by integration.

Step 2: Map Targeting into a Payload

Once you have IDs, you construct the targeting object.

Example: Geographic + demographic + audience

const targeting = {
  geographic: {
    countries: ['US'],
    regions: [{ id: '3843', name: 'California' }],
  },
  demographic: {
    ageMin: 25,
    ageMax: 54,
    male: true,
    female: true,
  },
  audience: {
    interests: [
      { id: '600313926646746', name: 'Technology' }
    ],
  },
};

Key concept

You are not mapping per integration.

You are using a consistent structure, and supplying provider-specific IDs.

Step 3: Apply Targeting at the Group Level

For most integrations, targeting is applied to the group (ad set / ad group).

const group = await sdk.ads.getAdsGroup({
  connectionId,
  id: groupId,
});

await sdk.ads.updateAdsGroup({
  connectionId,
  id: groupId,
  adsGroup: {
    ...group,
    targeting,
  },
});

This is the primary targeting workflow.

Step 4: Campaign Creation with Targeting

Campaign-level targeting is supported only by some integrations.

You can still include targeting in campaign creation:

await sdk.ads.createAdsCampaign({
  connectionId,
  adsCampaign: {
    name: 'Spring Campaign',
    status: 'ACTIVE',
    budgetAmount: 5000,
    budgetPeriod: 'DAILY',
    targeting, // applied where supported
  },
});

Important

• Some integrations will apply targeting at campaign level
• Others will ignore it or require group-level configuration

Your product should:

• support both patterns
• default to group-level targeting

Step 5: Provider Differences

Targeting capabilities vary.

Examples

• Meta Ads
  • supports most targeting types
• Google Ads
  • supports geographic and interest-based targeting
  • has different placement and optimization behavior
• TikTok Ads
  • supports a subset of targeting types
• Amazon Ads / X Ads
  • may only support countries and locales

What this means

You must:

• detect available targeting types
• limit UI options accordingly
• handle unsupported cases

Step 6: Fallback for Unsupported Targeting

If a targeting type is not available through the unified lookup:

• use the Passthrough API
• call the integration's native endpoint

This gives you access to provider-specific targeting while still using:

• Unified authorization
• connection management
• consistent request structure

Step 7: End-to-End Targeting Flow

// 1. Lookup targets
const countries = await sdk.ads.listAdsTargets({
  connectionId,
  type: 'countries',
  query: 'united',
});

// 2. Build targeting
const targeting = {
  geographic: {
    countries: [countries[0].id],
  },
};

// 3. Apply to group
const group = await sdk.ads.getAdsGroup({ connectionId, id: groupId });

await sdk.ads.updateAdsGroup({
  connectionId,
  id: groupId,
  adsGroup: {
    ...group,
    targeting,
  },
});

This is the minimal cross-platform targeting pipeline.

Why This Matters

Without a targeting lookup layer:

• you must map IDs per integration
• you must maintain lookup logic per integration
• you must validate targeting per integration

That becomes:

• fragile
• expensive
• difficult to scale

Unified changes this by:

• providing a unified lookup endpoint
• standardizing targeting structure
• allowing reuse across integrations

This removes per-integration mapping logic and reduces maintenance risk .

Key Takeaways

• Targeting is the hardest part of campaign management
• Each integration uses different identifiers and structures
• Unified provides a lookup endpoint for targeting IDs
• Targeting is primarily applied at the group level
• Campaign-level targeting is integration-dependent
• IDs should always be used for reliability
• Provider differences must be handled explicitly

If you're building campaign creation, optimization, or automation features, this is the layer that determines whether your product can support multiple integrations without custom logic.

→ Start your 30-day free trial

→ Book a demo