Connect Adobe Analytics

Previous Next

Connect Adobe Analytics

Connect a report suite to prepare its recorded traffic as a source for your AI shoppers. Squoosh verifies the credential and report suite, then reads aggregate reports.

Beta: pending live validation

Adobe Analytics remains at the connection stage. Its parser has fixture tests but has not run against a real Adobe tenant. Adobe readings are excluded from calibration and unattended snapshot refreshes until validation is complete. Connecting Adobe does not yet change your shopper pool.

Before you start

You need an Adobe Analytics subscription and access to a report suite. In the Adobe Developer Console:

  1. Open or create a project in your Analytics organization.
  2. Choose Add API, then Adobe Analytics.
  3. Choose OAuth Server-to-Server. This replaces the retired Service Account (JWT) credential.
  4. Assign a product profile with access to the report suite and metrics you want Squoosh to read.
  5. Copy the Client ID, Client Secret, and Organization ID from the credential overview. Review the credential's Scopes view if authentication fails.

Find the report suite ID (rsid) in Adobe Analytics under Admin > All admin > Report suites. Use the Report Suite ID, not the display name. See Adobe's Report Suite Manager.

The global company ID is different from the organization ID. An administrator can call GET https://analytics.adobe.io/discovery/me with Authorization: Bearer <access token> and x-api-key: <Client ID>. Use a companies[].globalCompanyId value from that response. See Adobe's Discovery API.

Connect Adobe Analytics

  1. Open Integrations, find Adobe Analytics, and click Connect.
  2. Enter your Client ID, Client secret, IMS organization ID, Global company ID, and Report suite ID.
  3. Optionally set Conversion metric. It defaults to metrics/orders; a custom conversion event can use a metric ID such as metrics/event12.
  4. Click Connect.

Squoosh obtains an access token and runs a one-day report against the configured report suite. The report probe checks suite access as well as authentication. A discovery response alone cannot prove that the credential can read the selected suite. Only the client secret is stored as a secret; the IDs are connection settings.

What it reads

Signal Adobe report Interpretation
Device Mobile device type, measured in visits Mobile phone becomes mobile, Tablet becomes tablet, and None becomes desktop. Adobe defines None as non-mobile devices. Label matching ignores case and extra whitespace.
Geography Countries, measured in visits Country names are retained and resolved by the shared country mapper.
Marketing channel Marketing Channel, measured in visits Not used. Adobe counts a visit in every channel it touched, so these rows are memberships rather than an acquisition split. Squoosh reads the report only to note whether channel processing rules exist and never produces a channel distribution from Adobe.
Conversion Orders, or the selected metric, alongside Visits Both counts come from the same day report and window. Orders counts purchase-event hits, not distinct converting sessions. The shared converter retains its existing cap at one conversion per session.

The window covers the previous requested number of complete days in the report suite's timezone, excluding today. Adobe evaluates the date formula, so UTC midnight and daylight-saving transitions do not determine which local dates are requested. See Adobe's report date-range reference.

Squoosh reads aggregate reports only. It does not write to the report suite or request visitor-level identifiers.

Limits and caveats

  • Desktop comes from None, not subtraction. Adobe defines this item as non-mobile traffic. The interpretation may include unknown user agents and is disclosed with a warning. Squoosh asks Adobe to return these items explicitly. See Adobe's mobile dimensions.
  • Device completeness is checked. If device-row visits differ from the same-window total by more than 1%, the device dimension is omitted. If more than 1% of device visits use unsupported labels, including Gaming console or Media player, it is also omitted. Smaller unsupported shares are excluded with a warning. These thresholds are Squoosh quality policies, not Adobe accuracy guarantees.
  • Partial reports do not become zeroes. Adobe can return HTTP 206 with metric or dimension errors. Squoosh omits errored columns and dimensions with warnings while keeping usable reports. Missing or disabled orders produces no conversion signal. A present, error-free orders column containing zero is a real zero. A 206 without usable error details is treated as unavailable. See Adobe's partial-response reference.
  • Marketing Channel data is not used. Squoosh still requests the Marketing Channel report, but only to record a warning that says whether the report suite has processing rules configured. Membership counts never enter the shopper pool or the sample size, because a visit can belong to several channels and the aggregate report does not establish which one acquired it.
  • Large reports are rejected when clipping is observed. Each report requests up to 1,000 rows. If Adobe indicates another page or more rows than were returned, Squoosh rejects the incomplete snapshot. It does not claim that a partial distribution is complete.
  • Rate limits still apply. Adobe documents 12 reporting requests per 6 seconds per user. Squoosh uses a 10-second request timeout and a 15-minute minimum snapshot refresh interval. Access tokens are reused in a bounded, isolated process-local cache until shortly before expiry; separate serverless workers can still mint separate tokens. See Adobe's API FAQ.
  • Validation is pending. The connector stays excluded from the shopper-pool blend and unattended data refreshes. Connection health checks remain available. The credential-specific scope list and several live response details still need tenant validation.

Troubleshooting

Problem What to check
Authentication fails immediately Confirm that the credential is OAuth Server-to-Server and the Client ID and Client Secret belong together. Check whether the secret was rotated.
HTTP 400 or a configuration error Check the global company ID, rsid, conversion metric ID, report suite timezone, and metric access. A permanent configuration error is not retried as provider downtime.
A permission error Grant the credential's product profile access to the suite and requested dimensions/metrics in the Adobe Admin Console.
A not-found error Compare the global company ID with /discovery/me and the rsid with Admin > All admin > Report suites.
No conversion signal Check whether the selected metric is implemented and enabled for the suite. Review partial-report warnings.
No device mix Review warnings for a partial response, missing device rows, row-total mismatch, or unsupported device labels.
No channel mix Expected. Adobe channel data is not used; see the caveat above.
Too many requests or timeout Retry later. Avoid repeated reconnects while investigating a quota problem.

Live validation checklist

For the team validating this beta connector, the existing harness command is:

npm run connectors:live -- adobe-analytics

It needs these environment variables:

  • LIVE_ADOBE_ANALYTICS_CLIENTID
  • LIVE_ADOBE_ANALYTICS_CLIENTSECRET
  • LIVE_ADOBE_ANALYTICS_ORGID
  • LIVE_ADOBE_ANALYTICS_GLOBALCOMPANYID
  • LIVE_ADOBE_ANALYTICS_REPORTSUITEID

Use an access-authorized credential scoped to a single report suite. Do not print secrets. Before promotion, capture the actual token/report shapes, confirm variables/mobiledevicetype through the dimensions endpoint, verify a disabled metric's 206 response, and record errors for a wrong company ID and rsid. Reconcile a 30-day snapshot against Analysis Workspace for the same suite and local date window: Visits, Orders, Mobile device type with None included, and Countries.

Fixture tests alone do not qualify the connector for promotion. Stage changes and unattended refresh eligibility belong to the separate promotion step.

Connect Matomo Connect Microsoft Clarity