Read and update analytics IDs

# 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](../tools/publ_analytics_tools_get.md) with an authorized channel:

```json
{"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](../tools/publ_analytics_tools_apply.md) 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.

```json
{
  "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.