The objects we sync from your CM360 account, the exact fields we read for each, and how they map into Medialake.
Medialake reads your CM360 structure (user profiles and their advertisers) to let you choose what to sync, and syncs the creatives and media assets behind your campaigns — all read-only, via Google's Campaign Manager 360 API (v5). We only read the fields listed on this page, nothing else. CM360 is a creative and asset integration: no performance metrics are captured.
Objects at a glance
CM360 object | What it is | Why we sync it |
Your access identity within a CM360 account | The entry point — every API request is made on behalf of a user profile | |
A brand or business within the account | Captures the hierarchy — the level you select for syncing | |
The visual content specification of an ad | Contains the assets — links each Medialake file to its creative context | |
Creative Asset (within each creative) | An individual media file inside a creative | Medialake ingests these as files — images, videos, and audio |
User Profiles & Advertisers
The CM360 hierarchy runs User Profile → Account → Advertiser → Campaign → Ad → Placement (see Google's trafficking overview). Creatives attach at the advertiser level, so Medialake reads the top of the tree live from the API for browsing and selection — profiles and advertisers aren't stored as records themselves. We keep only your selections and, on each ingested file, the profile, advertiser, and creative IDs it belongs to.
User profile fields we read:profileId, userName, accountId, accountName
Advertiser fields we read:id, name
Creatives
For each synced advertiser we read its creatives from creatives.list and the assets inside them, so every file can be matched to the creative it serves in.
Fields we read:id, name, type, active, size, lastModifiedInfo.time, and the creative's creativeAssets list. The creative context (profile, advertiser, and creative IDs, name, type, size, last modified) is stored on each ingested file.
Media assets
Each creative's creativeAssets become files in Medialake. How the media is retrieved depends on the asset type:
Videos & audio (
INSTREAM_VIDEO/VPAID/INSTREAM_AUDIO): the API provides serving URLs for these assets. CM360 lists the original upload plus one transcode per rendition of the same source, so Medialake ingests one file per creative — the original upload where available, otherwise the highest-quality transcode. If a stored URL stops working, a fresh one is fetched from the API and the download retried.
Fields we read:id, assetIdentifier (type and file name), fileSize, mimeType, mediaDuration, bitRate, role, progressiveServingUrl / streamingServingUrl
Images (
HTML_IMAGE/IMAGE): the CM360 API exposes no download URL for image assets, so Medialake retrieves them from Google's public ad-serving CDN, verifying each URL before use.
Fields we read:id, assetIdentifier (type and file name), fileSize, size, role
Not ingested:
HTML(HTML5 zip bundles) and legacyFLASHassets — the API exposes no URL for them, and each such creative also carries a backup image which is ingested, so the creative stays visually represented.TRACKING_TEXTcreatives contain no assets at all.
How it maps into Medialake
User Profile
└─ Advertiser
└─ Creative
├─ File (image — retrieved from Google's ad CDN)
└─ File (video / audio — best rendition, via serving URL)Everything on this page is read-only — see Authentication for the permissions behind it.
Further reading (Google documentation)
Trafficking overview — the CM360 object hierarchy
Questions about a specific field? Contact [email protected].