Content Recommendations Overview

Arc XP’s Content Recommendations delivers personalized content recommendations for your audience by learning from your content catalog and your readers’ behavior. It works with any CMS and any web stack, and serves recommendations to any surface.

Start here to understand how an integration fits together — then follow the guide for the path that matches your stack.

The three parts of an integration

Every integration has the same three moving parts:

1. Content catalog sync — your CMS keeps the recommender’s catalog current by posting publish, update, and delete events to the Content endpoint (POST /collector/v1/content). Arc XP CMS customers wire this up with the IFX Recipe. This part is the same regardless of how you collect behavioral events.
2. Behavioral event collection — your site sends reader interactions (page views, clicks, scroll depth) to the event collector. This is the part with two options, covered below.
3. Recommendations read — your applications call GET /recommend/v1/recommendations to fetch a ranked, display-ready list for a user. This part is the same regardless of how you collect behavioral events.

The rest of this page focuses on the one decision that differs between integrations: how you collect behavioral events.

Choose how to collect behavioral events

There are two supported ways to get reader behavior into the recommender. Both feed the same model and the same recommendations read path — the choice is about where your behavioral signal comes from and how much you want to build.

	Compass Web SDK	CDP / server-side forwarder
What it is	Arc XP’s first-party client-side JavaScript library (@arcxp/compass-sdk, global ArcCompass) you embed in your web pages	A translation you write on your side that maps your event source onto the event envelope and POSTs it
How events are sent	The SDK captures and posts events for you	You POST events yourself
Collector endpoint	collect-web/v1/events/batch (browser events collector)	collector/v1/events (server-side Collector API)
Reach	Browser only	Any source — server-side, native apps, OTT, backfill
Built in	Automatic page_view capture (incl. SPA routes), consent gate, identity + session management, batching, retry	You own batching, retry, identity stability, and consent filtering
Effort	Paste a snippet, call init(), resolve consent — roughly one hour	Build (or template) a forwarder against your source

Use the Compass Web SDK when…

• Your behavioral signal is primarily web/browser traffic.
• You don’t already forward events from a CDP and don’t want to build a server-side pipeline.
• You want the fastest integration with batching and retries handled for you.

Go to the Compass Web SDK: Integration Guide.

Use a CDP / server-side forwarder when…

• Events originate server-side or from non-web surfaces (native apps, OTT) that the browser SDK can’t reach.
• You already operate a CDP — BlueConic, Amplitude, Adobe Real-Time CDP, Tealium, Permutive, ActionIQ, and similar.
• You need historical backfill or you collect behavior in an analytics warehouse (GA4 in BigQuery, Sophi).
• You want a single server-side pipeline of record for all event traffic.

Go to Connect Your CDP to the Recommender API.

Use both when…

The two paths are not mutually exclusive. A common pattern is to run the Compass Web SDK for live web traffic and a forwarder for historical backfill or non-web surfaces. When you combine them, keep the join keys consistent: send the same anonymized user_id for the same reader and the same item_id for the same content across both paths, or the model treats the two streams as unrelated. See the Item ID Guidance.

Note

Which collector base path? Two collector prefixes appear across these guides, and they are not interchangeable:

• collect-web/v1 — the browser events collector the Compass Web SDK posts to.
• collector/v1 — the server-side Collector API that forwarders and your CMS post to (both events and content).

Both train the single recommendation model for your tenant.

What’s shared across both paths

No matter which collection path you pick, these hold:

• Content catalog sync happens through the Content endpoint (or the IFX Recipe) — independent of your event-collection choice.
• item_id and user_id conventions are the same. user_id must be anonymized (never PII) and stable per reader; item_id must be a stable CMS record ID used identically in content and events. See the Item ID Guidance.
• The recommendations read path (GET /recommend/v1/recommendations) is identical, and each item returns a display-ready card.

Where to go next

• Content Recommendations API Developer Guide — endpoints, authentication, event/content field references, and troubleshooting (the core reference for both paths).
• Compass Web SDK: Integration Guide — the client-side path.
• Connect Your CDP to the Recommender API — the server-side / CDP path.
• Content Recommendations Onboarding Checklist — phase-by-phase rollout for either path.