publ betaReference (MCP guide)
Open publ console

publ Reference

Read and update analytics IDs

Google Analytics, Google Tag Manager, Meta Pixel, Kakao Pixel and Naver Premium Log share one get/apply workflow.

Read the selected screen

Use analytics_tools_get with an authorized channel:

{"channelCode":"selected-channel-code"}

Retain revision and inspect initialized, settings and recacheDomain. A custom-record 404 requires an explicit apply to initialize; the reader creates nothing. DNS 404 leaves the connected domain unverified and permits the source channel-only recache path.

Plan the requested fields

Use analytics_tools_apply with the fresh revision and a stable requestId. Omission preserves an ID; an empty or whitespace-only string clears it. All whitespace is removed from supplied IDs; nonempty Google values require G- or GTM- prefixes. Values are not checked with third-party providers.

{
  "channelCode":"selected-channel-code",
  "requestId":"analytics-guide-plan-001",
  "expectedRevision":"0000000000000000000000000000000000000000000000000000000000000000",
  "settings":{"gaTrackingId":"G-EXAMPLE","gtmId":"GTM-EXAMPLE"},
  "dryRun":true
}

Replace the placeholders before use. Inspect PLAN_READY and its normalized settings, initializationRequired, changesRequired and recacheRequired. A new dry run sends no business write and creates no journal. A changed plan still requires configured CHANNEL_ENV, DNS and ROBO_FRIENDLY services. To execute a user-authorized change, use the intended fields/current revision with dryRun:false, which is also the default if omitted.

The revision protects the entire custom record and domain observation. A conflict can result from an unrelated custom-setting or timestamp change. Read again and reassess the plan; do not rewrite a revision or old journal to force it through.

Report saved state and recover carefully

The workflow may initialize, sends one partial settings PUT, verifies all omitted business settings, requests recaching and reads back again. These are separate steps; a recache failure does not undo saved settings. Report the save and cache acknowledgements separately. HTTP 200/204 recache acknowledgement does not prove cache freshness, visitor execution, consent, provider ownership or event delivery.

Retain taskType analytics-tools and the original taskId. Status reports history; resume may continue untouched stages. Sent initialization/save requests can be reconciled by full readback and are never resent. A sent recache stays held for manual inspection even after an explicit failure. Do not use a new task merely to retry caching. Pending lastVerifiedSettings is a saved checkpoint with lastVerifiedSettingsAreCurrent:false; call get for current values.

A completed replay is historical:true with verification.confirmed:false. An unchanged no-op can complete without any save/cache acknowledgement. For a deliberate later restoration, first read the current state and use its revision in a separately authorized change; this is not automatic rollback or a retry of the old task. Keep uncertain journals intact.

The returned console destination is for this channel's analytics screen; a URL alone does not prove console access or visible UI state. Initial-record creation, other roles, observed-domain recache, forced renewal, autonomous LLM selection and hosted/visitor behavior require their own evidence.