MarTech Products

A product catalog is usually the least interesting page on a directory: a list of names, each leading to a list of firms. It is more useful read as a map of decisions. Almost every expensive mistake in marketing technology is a category error made early — two analytics products bought because nobody decided which one was the source of truth, a customer data platform bought to do a warehouse's job, an orchestration tool chosen for the wrong customer motion.

This page is about those choices rather than about any single tool. It covers how the Adobe and Google stacks are organised differently, which products are routinely mistaken for alternatives, what each one actually asks of the people who run it, and the order in which a multi-product programme tends to succeed.

Two ecosystems, two organising logics

Adobe Experience Cloud is a set of separately licensed applications that share an identity and data spine. You can run Adobe Analytics for years without touching Experience Manager, and plenty of organisations do. That modularity is the point, but it has a consequence: an Adobe programme is almost always an integration programme. The demanding work is rarely inside one application — it is in the schemas, identities and hand-offs between them, which is also where it goes wrong.

Google's stack splits across two families with genuinely different buyers. Google Marketing Platform — Display & Video 360, Search Ads 360, Campaign Manager 360 and Analytics 360 — is bought by media and measurement teams and run as a daily operation. Google Cloud — BigQuery, Looker, Vertex AI and the infrastructure beneath them — is bought by data and engineering teams and run as a platform. A firm described as a Google partner may be fluent in one half and effectively absent from the other.

So the first question a catalog should help you answer is not who the best partner is. It is which half of which stack the project actually lives in, because that single fact eliminates most of the field before you have read a word about any individual firm.

Products that get mistaken for alternatives

Several products here answer adjacent questions rather than the same one. Treating them as competing options is how budget gets spent twice on one capability and not at all on another.

• Adobe Analytics, Customer Journey Analytics and GA4 — three answers to what happened. Customer Journey Analytics sits on Experience Platform and reports across stitched, cross-channel data. Adobe Analytics reports on its own collection model, with a long lineage of implementations behind it. GA4 is event-based and starts free, which is why it tends to end up alongside the others rather than instead of them. Running two without deciding which is the reporting source of truth is one of the more reliably expensive habits in the stack.
• Real-Time CDP and the data warehouse — Real-Time CDP exists to activate: assemble profiles and push segments to destinations quickly. BigQuery exists to model and analyse. Teams that buy a CDP expecting warehouse economics, and teams that model everything in the warehouse expecting activation, both tend to rebuild the missing half a year later.
• Journey Optimizer, Campaign and Marketo Engage — orchestration for three different customer motions. Journey Optimizer for event-triggered cross-channel journeys built on Experience Platform data. Campaign for high-volume scheduled and transactional messaging. Marketo Engage for lead lifecycle, scoring and sales hand-off. The right choice follows from whether the motion is consumer messaging, B2B pipeline, or reacting to behaviour in near real time.
• Display & Video 360, Search Ads 360 and Campaign Manager 360 — not a shortlist to pick from. DV360 buys programmatic inventory, SA360 manages search across engines, and CM360 serves and measures advertising regardless of where it was bought. They occupy different seats, and a media operation frequently needs more than one.
• Target and on-site experimentation — Adobe Target covers server- and client-side testing alongside rules-based and algorithmic personalisation. Bought to run A/B tests alone, it is an expensive way to answer a question that cheaper tools answer; its value sits in the personalisation half, which is also the half that needs a content and data supply chain behind it.
• Experience Manager and a general-purpose CMS — AEM is often evaluated against lighter content tools on page-building features, which is the wrong axis. Organisations choose it for asset management at scale, multi-brand governance and localisation workflow. If those are not the problems you have, the comparison flatters the alternatives.

A licence is not a capability

The skills these products demand differ far more than their positioning suggests, and that difference decides whether a partner can actually deliver. Two firms can hold comparable certifications on paper and be unable to staff the same project.

• Experience Manager — Java, OSGi, Sling and the JCR content model, plus editorial operations to keep it fed. Its dominant cost is developer months, not licence. Edge Delivery Services changes the front end and the performance story; it does not remove the need for content engineering.
• Adobe Commerce — a PHP codebase with Magento lineage, catalog and pricing complexity, and an upgrade cadence that punishes heavy customisation. The useful question is how a partner handles version upgrades, not whether they can build a storefront.
• Customer Journey Analytics — schema and identity modelling on Experience Platform. It is data engineering wearing an analytics costume, and staffing it with a reporting analyst is a common and predictable failure.
• BigQuery and Looker — SQL and transformation discipline, usually with dbt or an equivalent, plus real cost governance. An unmanaged warehouse becomes a finance problem before it becomes a data problem.
• DV360 and SA360 — daily trading operations: pacing, inventory quality, bid strategy, brand safety. This is a staffed desk rather than a project with an end date, and it is the clearest case in the catalog where ongoing capacity matters more than implementation skill.
• Marketo Engage — lifecycle design and CRM synchronisation. Most of what goes wrong is process design and data hygiene rather than the platform, so ask about lead routing and deduplication before anything else.
• Workfront — process and governance design. The technical build is modest; the organisational change is the project, and it is why Workfront engagements fail for reasons that have little to do with software.
• Vertex AI and the modelling layer — MLOps practice: feature management, evaluation, monitoring and rollback. Models demonstrably running in production matter far more here than familiarity with the console.

The order that tends to work

Multi-product programmes fail less often on tool choice than on sequence. Personalisation built on untrusted measurement produces confident nonsense, and journeys built before consent plumbing produce legal exposure. A rough order holds across most of this catalog.

1. Settle collection and identity. Decide what you collect, how a person is recognised across channels, and which system owns that definition. Every later product inherits this decision, and re-deciding it mid-programme is the most costly rework in the stack.
2. Make measurement trustworthy. One reporting source of truth, reconciled against a second source and against the business's own numbers. Until stakeholders believe the reporting, nothing downstream gets adopted.
3. Wire consent before orchestration. Consent state has to travel with the data rather than sit beside it. Anything touching European traffic needs this settled before journeys are switched on, not retrofitted afterwards.
4. Then activate and personalise. Segmentation, journeys and on-site experience, resting on data people trust and permissions that hold up to scrutiny.
5. Add modelling and AI last. Predictive scoring and generative content are multipliers on a working foundation and amplifiers of a broken one.

Hybrid Adobe and Google stacks are the normal case

This catalog is organised by ecosystem, but very few real stacks are. GA4 runs alongside Experience Manager because it was already there and free. BigQuery sits beneath Experience Platform because the analytics team needed a warehouse the CDP was never going to be. Search Ads 360 spend gets reported in Adobe Analytics because that is where the executive dashboard lives.

These seams are where projects stall, and they are invisible in certifications. A firm can be genuinely excellent on the Adobe side and still have never moved consented identifiers into BigQuery, or built server-side collection that satisfies both an Adobe schema and a Google measurement model. When a requirement crosses ecosystems, interrogate the integration — who owns identity, where transformation happens, what breaks when one side changes — rather than the badge on either side of it.

It is also a practical filter on a shortlist. Ask for a named engagement where the firm delivered across the specific seam you have. Firms that have done it describe it in specifics; firms that have not describe it in capabilities.

How to read this catalog

Each product above carries a plain-language description of what the tool does, the delivery realities specific to it, and the firms with publicly documented expertise in that product. Documented means the claim traces to a public source — an official Adobe or Google partner directory listing, the firm's own site, or a published case study — rather than to anything a firm told us privately.

Two things this catalog deliberately does not do. It does not rank firms by quality, and it carries no reviews, ratings or scores, so the order tiles appear in is not a verdict on who is better. It also does not treat partnership tier as a proxy for product skill: tiers are awarded largely on commercial performance across a whole ecosystem, and a specialist with three relevant projects is often the better answer than a top-tier generalist who has never run your product under pressure.

The workflow worth following is narrow. Identify which product the project genuinely centres on, read what that product demands of a team, build a shortlist from firms whose documented work matches it, then test that shortlist with a brief specific enough that generic answers become obvious.