Sportland’s eCommerce team had spent years building more than 100 recommendation blocks by hand, each one a careful guess at what a customer would want next. Then they switched on Bloomreach’s AI engine, and its recommendations converted 6x higher.

We covered this story in our recent panel discussion with Sportland and Bloomreach. Sportland’s marketing and eCommerce leads walked through their customer data platform, what it cost them in time and attention, migration to Bloomreach, and what they would do differently today. Read the rest of the article for the highlights, or here’s the recording if you prefer to watch:

Where Sportland started

Sportland opened its online store in 2020, during the first store closures, which the team itself calls late. The following years went into the eCommerce foundation, then customer experience, then performance, and new markets. Personalization only came up in the middle of that journey, when the email tool and the data behind it could no longer keep up with what the team wanted to do.

The data about customers was there, in spreadsheets, in the ERP, in the Adobe Commerce backend, and in the email platform. What was missing was any connection between them. And with five markets, Estonia, Latvia, and Lithuania plus smaller operations in Finland and Poland, every flow, web layer, and recommendation engine was built three or four times over.

One more thing a multi-market retailer should know. The biggest market has several times the customer data of the smallest, so personalization left to itself widens the gap between strong and weak markets. It has to be designed against, or the best work ends up where it is least needed.

CDP project goals

CDP was set to bring more revenue from email and a better return on ads. It would also improve automation, multi-market support, and behavior-based journeys. Email moved from scheduled newsletters toward messages triggered by what a customer does, running on their own. They were also going to build audiences from Sportland’s own customer data and push them to Google and Meta. Personalization was never the goal as such. A new customer, a repeat customer, someone into one brand or one sport, someone about to lapse, each should get different communication and a different share of the budget.

What a CDP does

A customer data platform brings everything known about a customer into one profile, from every channel and source. Marketing automation acts on that profile, deciding where a journey starts, what gets personalized, and when to stop.

In Bloomreach, the AI layer, Loomi, sits inside the platform and takes over decisions that used to be made by hand. It finds the best segment for a campaign from different combinations, writes copy in a set tone of voice, ranks products per visitor, and in what Bloomreach calls contextual personalization, it sends each customer the test variant that people like them responded to, even when that variant lost the overall A/B test.

The next step is agents. In the webinar, the demo showed an abandoned-search campaign, with scenario, emails, and dashboards, built from a single request. One Bloomreach client puts the time saved on campaign creation at around 92%.

Sportland’s CDP setup

Follow one customer in Tallinn through it:

• The customer sees a Sportland ad for road running shoes on Instagram →
• On the homepage, they get what is popular, because they’re still anonymous →
• The customer creates a Sportland ID →
• Their anonymous history merges into their profile →
• From that point, product pages show alternatives in this customer’s size that are in stock, and search results are ranked for them specifically →
• If this customer leaves at payment, they get a reminder, and 9.6% of those reminders turn into an order →
• After delivery, comes a survey and picks chosen for this customer, with a cap on how often they hear from the brand →
• Two months of silence, and they gets the new season’s version of the shoes they bought, in their size and brand →
• A year on, Sportland still knows which group this customer belongs to and writes to them accordingly.

One campaign plan across markets

The campaign side did not get more complicated. Sportland works from one group-wide campaign plan, so the three Baltic markets usually run the same campaign at the same time across email, paid media, web, and stores. The copy is translated and the imagery is local, with each market’s own athletes and influencers.

The personalization is underneath – a running campaign carries one message, but a heavy runner and an everyday runner get different emails, recommendations differ per market, and the automated flows keep running regardless of the campaign calendar.

Results

• +62% more revenue on the same ad spend
• +24% orders from automated flows
• +24% conversion rate on personalized recommendations
• +9.6% of checkout reminders end in an order
• Automated flows are a small share of what Sportland sends and bring over 30% of its email revenue.

What Sportland would do differently

• Define the first few business problems before exploring what the platform can do. A platform this broad is easy to get distracted by, so pick a use case with a real customer problem, the data to act on it, and a result you will measure. Start small, test, understand why it works, then widen.
• Plan for ownership on day one, because the platform launched fast, but changing how the organization works with it took far longer than expected. A partner matters early, but the long-term goal is for nobody outside the company to know the setup better than the company does. Sportland is now moving from built for us to built with us.
• Get the architecture right before activation. Flows convert within two weeks, so everyone wants to launch them first, but how markets are separated, how identity resolves, and what gets tracked cannot be undone cheaply later.

A project like this runs in three phases, and each needs a different team:

1. Build covers data mapping, integrations, migration, and testing, and carries the biggest decisions.
2. Setup and run covers local coordination, reporting, optimization, and content, and for Sportland that is where scandiweb did much of the running in the first period.
3. Control is where the internal team owns the platform end to end and calls the partner for specific things. Sportland now handles around 80% of the work internally, and the advice is to decide who will own that last phase before the build starts.

Want an outside view on your own personalization setup? Get in touch with a CDP strategist and book a free discovery and data audit.

The post Webinar Recap: How Sportland Runs AI Personalization Across 3 Baltic States appeared first on scandiweb.

Automated flows now generate 39% of Sportland’s email revenue from just 3% of sends. 12 months after the CDP launch, email orders are up 20.6% and paid media has returned 9.5% more revenue on 21.3% less spend, lifting ROAS 39.1%.

Behind those numbers is a rebuild of how they collect and use customer data, with scandiweb’s team owning the personalization strategy from initial integration through the AI-driven experiences running today.

About

Sportland is the leading sportswear retailer in the Baltics, known for its award-winning in-store experience and broad omnichannel presence. Their business operates across multiple countries, with distinct store views and marketing teams in each market.

While they had already made strides in building a strong data foundation, marketing activation was still tied to costly tools, which were limited in terms of the email marketing automations Sportland wanted to implement.

They required a solution capable of supporting multiple markets, distinct store views with different languages and product assortments, and siloed customer data. Even before the project began, this complexity presented a significant challenge, as any prospective platform needed robust configuration options to manage user consent data, customer accounts, and product catalogs effectively for campaign execution.

Rather than move to another standalone email service provider, scandiweb helped Sportland rethink the foundation.

Project goals

To fix fragmented customer data and disconnected marketing touchpoints, we implemented a customer data platform (CDP). The decision to move away from a standalone email marketing platform opened the door to a broader transformation in how Sportland manages and uses customer data in multiple markets with distinct store views and separate customer data handling.

A properly implemented CDP enables:

• Centralized collection of data from eCommerce, ERP, POS, email, SMS, support, and more
• A 360-degree customer view built on resolved identities and real-time data updates
• Advanced audience segmentation using predictive metrics and behavioral insights
• Multi-channel campaign delivery with unified messaging across email, ads, and website content.

Project goals for Sportland’s CDP integration included:

• Migrate the whole email marketing setup from Klaviyo to Bloomreach
• Consolidate fragmented customer data across markets into a unified CDP framework
• Implement tracking for user behavior across the whole customer journey using the Bloomreach SDK
• Integrate backend purchase and refund data via Google BigQuery
• Build robust email automation flows, improving upon and expanding what was possible in Klaviyo
• Enable A/B testing, predictive segmentation, and automated product recommendations
• Sync audiences with Meta and Google Ads for personalized paid marketing
• Establish privacy-compliant consent management
• Ensure performance is measurable through reporting dashboards in Bloomreach and Looker Studio.

For more insight into CDPs, watch a recording of our webinar, or read more for all the essentials on how CDPs can help eCommerce retailers grow their revenue:
How to Increase Your eCommerce Revenue 2-3x with CDPs

Approach

Sportland knew they had outgrown Klaviyo, but the alternative needed to support more than just email. We assisted in the selection process by comparing capabilities and costs across several CDP solutions. After a series of discovery sessions and technical deep-dives, Bloomreach was chosen for its ability to unify data across channels and support scalable marketing automation.

Email marketing platform selection

An often-overlooked factor in marketing platform comparisons is the management and execution perspective – how intuitive it is for teams to build templates, manage dynamic content, and launch campaigns on a day-to-day basis. 

We chose to migrate to Bloomreach because of its smooth content creation experience, which made assembling emails faster and more efficient. More importantly, it integrated email, CDP, product recommendations, and on-site personalization into a single system, enabling a unified, 360-degree view of the customer and a stronger omnichannel strategy.

Initially focused on site search and recommendations, Bloomreach has expanded its capabilities into marketing automation and CDP solutions. Bloomreach’s Composable Personalization Cloud combines data ingestion, AI-driven segmentation, identity resolution features, and delivery through native integrations in one place, enabling the collection and unification of customer data while delivering personalized experiences and messaging to brand customers. 

Klaviyo remains a strong option for smaller Shopify merchants, but Sportland’s growth and channel complexity called for a more advanced, unified solution.

CDP setup for a multi-market business

Sportland operates across multiple countries, each with its own store view and customer database. A central question was whether to consolidate all markets into one project or split them by country. While a unified project promised simplicity, overlapping data and conflicting user IDs made that approach impractical. Based on our recommendation, we implemented a market-specific structure to preserve data integrity and avoid downstream issues.

In the architecture we built, data flows into Bloomreach from Sportland’s core business systems on one side, and marketing activation flows out to every customer touchpoint on the other.

What feeds Bloomreach

• Magento (eCommerce)
• ERP system
• GA4 and BigQuery (behavior and backend data)
• Google and Meta ads data
• Additional sources like POS data are already scoped for the next phase, extending the customer view into physical stores and explicit customer signals.

What Bloomreach powers

• Email automated flows and campaigns
• Email content personalization
• Google and Meta audience syncing
• Weblayers
• On-site content blocks and personalization
• Personalized search
• Looker Studio performance reporting.

Every data source enriches a single customer profile, and every activation channel draws from that same profile.

Configuring the foundation

We then began tailoring the Bloomreach setup to Sportland’s data ecosystem:

• Defined tracking requirements across the entire user journey
• Implemented the Bloomreach Web SDK to capture on-site behavior
• Structured product catalog attributes and configured the data pipelines
• Integrated backend customer, order, and refund data from Google BigQuery with regular syncs into Bloomreach.

Because Bloomreach pricing is tied to the volume of events processed and stored, it was essential to estimate yearly traffic and optimize tracking from the start. We disabled non-essential auto-tracked events and fine-tuned the implementation to retain key data points without overspending.

To ensure user privacy, we implemented proper consent logic for event tracking. This was integrated with existing frontend controls so that marketing data collection respects user preferences in all markets.

Campaign setup and automation

We redefined and significantly expanded email automation flows compared to their Klaviyo setup. These flows were tailored per market, taking into account local behavior and store-specific logic:

• Browse abandonment flows
• Post-purchase product recommendations
• Multi-step cart abandonment
• Welcome series variations
• Targeted outlet campaigns.

Automated flows now generate 39% of Sportland’s email revenue while accounting for just 3% of sends. With a properly tuned lifecycle program, the right message gets to the right person at the right moment, at scale, without a marketer overseeing every send-out.

We also moved Sportland from generic “active subscribers” targeting to intelligent segmentation using RFM and predictive models. Segmented flows now generate +18% revenue per recipient compared to generic sends.

PPC strategy

We connected Bloomreach to Google and Meta Ads, enabling audience syncing, including predictive segments based on AI-driven purchase likelihood and RFM models.

Product recommendations were also migrated from Clerk.io to Bloomreach, requiring extensive QA and catalog mapping to ensure consistent logic across web and backend data layers. Our internal feed management tool played a key role in syncing enriched product data with Bloomreach.

To support decision-making outside marketing teams and provide more accessible performance insights, we built reporting views in Bloomreach and Looker Studio. It enables internal stakeholders to monitor and optimize campaigns without needing to navigate the CDP backend.

From rule-based to AI-driven personalization

On-site recommendations started rule-based, where someone had to decide in advance what to show whom. Our site personalization & optimization team migrated Sportland to Loomi AI-powered recommendations that learn from behavior and adapt in real time.

Early data from the newly launched blocks shows a 2.4x conversion increase versus the older rule-based version. An even bigger win is that this personalization engine is repeatable across markets, and every new market Sportland launches inherits it.

Results

Within months of launching the new CDP, Sportland saw improvements in email marketing and paid media. The ability to unify backend data with behavioral signals enabled more relevant, better-timed communications, while automation and audience targeting became significantly more advanced compared to the previous setup.

Email marketing

• +20.6% orders
• +11.3% placed order rate
• +10.4% revenue in the first few months after launch
• +48% revenue YoY due to automated flows and predictive segmentation.

Paid media performance

• +39.1% ROAS
• +9.5% revenue
• +25.1% average order value

– all while marketing spend was reduced by 21.3%.

Google Ads

• +29.6% conversions
• +72.2% ROAS
• +18.5% revenue
• -31.2% cost

Project outcomes

• Market-specific CDP setup in place to reflect Sportland’s multi-store structure
• Sync between frontend and backend customer data
• Fully redesigned email automation flows
• Consolidated campaign performance reporting in Bloomreach and Looker Studio
• Seamless transition from Clerk.io to Bloomreach for product recommendations
• Rule-based recommendations replaced with AI-driven Loomi personalization, repeatable in all markets
• Sportland’s team now can manage content blocks and launch campaigns independently
• Dedicated CX strategist tying email, paid, and on-site together into a real lifecycle strategy, turning the CDP from a data platform into a business growth engine.

The setup is built to keep growing – new markets inherit the personalization engine, new channels plug into the same customer view, and Sportland’s team owns it, running and expanding the system independently.

A CDP is a way to align your data, teams, and channels around your customer needs. Request a free consultation with our Analytics team, and let’s build a system that works seamlessly, leading to more effective marketing, much stronger customer loyalty, and overall better business results.

The post CDP Case Study: Multi-Market Personalization for the Biggest Baltics Sportswear Retailer appeared first on scandiweb.

If you have been searching for “Salesforce Data Cloud” and finding more recent results that mention “Data 360” instead, here is the short version. Salesforce rebranded Data Cloud to Data 360 at Dreamforce 2025. The product underneath the name is the same customer data platform you may already be evaluating – the brand position around it has changed substantially.

This guide covers what the rebrand means for eCommerce teams choosing a CDP in 2026, how Data 360 works, what it does that earlier CDPs could not, and how to prepare for a deployment. The way scandiweb frames it for clients is simple: the platform itself is mature, and the Agentforce 360 ecosystem around it is where most of the 2026 decisions actually live.

Overview

• Salesforce Data Cloud was rebranded to Data 360 at Dreamforce 2025 (October 14, 2025) as part of the wider Agentforce 360 platform shift.
• Data 360 is the only data engine native to the Salesforce platform – it ingests, unifies, segments, and activates customer data across Commerce Cloud, Marketing Cloud, Service Cloud, and Sales Cloud in real time.
• The CDP capabilities did not change with the rebrand. The strategic positioning did – Data 360 is now framed as the live context that fuels AI agents (Agentforce), not as a standalone customer data warehouse.

What is a customer data platform?

A customer data platform (CDP) is a system that ingests customer data from multiple sources, unifies that data into a single profile per person, and makes the unified profile available to downstream applications for segmentation, personalization, and analytics. Unlike a CRM (which stores known relationships and interactions) or a data warehouse (which stores historical data for analysis), a CDP is built to serve real-time customer-facing decisions across web, mobile, email, and service channels.

For a broader treatment of the CDP category, see scandiweb’s guide to customer data platforms for eCommerce.

What is Salesforce Data 360 (formerly Data Cloud)?

Salesforce Data 360 is the customer data platform built natively into the Salesforce ecosystem. It ingests customer data from any source – web events, mobile apps, transactional systems, marketing platforms, in-store POS, third-party data – and unifies it into a single real-time customer profile that every Salesforce cloud (Commerce, Marketing, Service, Sales) can act on. As of October 2025, it falls under the Agentforce 360 umbrella alongside Salesforce’s AI agent platform.

Why the rebrand from Data Cloud to Data 360

Salesforce has renamed this product five times. The lineage runs Customer 360 Audiences, Salesforce CDP, Marketing Cloud Customer Data Platform, Salesforce Genie, Salesforce Data Cloud, and now Data 360. The Dreamforce 2025 rebrand reflects a strategic shift. Salesforce no longer positions the product as a static data warehouse. The 2026 framing is “live context that fuels AI, automation, and decision-making across the enterprise” (per Apex Hours analysis of the rebrand announcement).

For evaluation teams, the rebrand changes nothing functional in the short term. The license, the data model, the integrations, and the segmentation tools work the same way they did under the Data Cloud name. What changes is the roadmap – every new feature in 2026 lands under the Agentforce 360 umbrella, which means AI-agent integration is now a built-in expectation, not an add-on.

Why use Salesforce Data 360 for eCommerce?

Data 360 is the right CDP choice for eCommerce teams in three specific scenarios.

You already run on Salesforce Commerce Cloud, Marketing Cloud, or Service Cloud

The native integration is the headline benefit. Data 360 talks to other Salesforce clouds without third-party connectors, without ETL middleware, and without API latency. A unified customer profile created in Data 360 is immediately visible in Service Cloud (so agents see real-time context), in Marketing Cloud (so journey builders trigger on live behavior), and in Commerce Cloud (so storefronts personalize on the next page load). For teams already inside the Salesforce ecosystem, this removes the integration tax that an external CDP would charge.

You are running headless or composable commerce and need a real-time customer profile

Headless and composable architectures decouple the storefront from the backend, which means the customer profile cannot live on a monolithic platform. Data 360 acts as the live context layer that any frontend (Magento PWA, Shopify Hydrogen, custom React storefront) can query for personalization and segmentation. scandiweb’s own Läderach Salesforce Data Cloud deployment uses this pattern to unify online and in-store customer signals for the luxury chocolate brand.

You want to deploy AI agents (Agentforce) on top of the CDP

This is the Dreamforce 2025 thesis in operational form. Agentforce agents (sales assistants, service agents, marketing strategists) need live customer context to be useful. Data 360 is the data engine that gives them that context. If your 2026 roadmap includes any of Agentforce’s eCommerce-relevant agents, you are committing to Data 360 whether you call it a CDP decision or an AI decision. The same logic applies if you are building out the analytics layer underneath – scandiweb’s eCommerce data analytics practice threads Data 360 into the reporting stack so the CDP is not a black box to the analytics team.

What Data 360 actually does

What is the Customer 360 Data Model?

The Customer 360 Data Model is the structural foundation underneath Data 360. It is the standardized schema that lets data from any source (CRM, ERP, web, mobile, POS) connect to a single customer profile. Without a shared model, every new data source would require custom mapping, and the integration would collapse under its own complexity within a year.

How the model handles fragmented data

Most enterprises have customer data scattered across five to fifteen systems – the CRM has contact records, the ERP has order history, the web platform has anonymous session data, the email tool has engagement signals, and the loyalty system has redemption activity. The Customer 360 Data Model provides standardized entities (Individual, Account, Order, Engagement, Loyalty Program Member) so that any source can map into them without bespoke ETL logic.

Components of the model

• Subject area: a logical grouping of related data objects (Sales, Service, Marketing, Loyalty, Commerce).
• Data stream: a single source feeding data into Data 360 (a web SDK, an S3 bucket, a Salesforce connector).
• Data Model Object (DMO): a structured grouping of data derived from streams and ready for use in segmentation, calculated insights, or activation.

How to prepare for a Data 360 implementation

scandiweb runs every Data 360 (and previously Data Cloud) project through the same six preparation steps. The order matters, and skipping the first three is the most common cause of a deployment that ships on time but does not deliver value.

1. Define the business outcome before the technical scope

Data 360 is a means, not an end. The first conversation with stakeholders should answer one question: what decision becomes easier when the unified profile exists? “Personalize the homepage hero by RFM segment” is a usable answer. “Implement a CDP” is not. The technical scope flows from the business outcome.

2. Identify all stakeholders, not just the technical sponsors

Data 360 touches Marketing, Service, Sales, Commerce, Legal (data privacy), IT (integration), and Operations (loyalty, fulfillment). Missing one stakeholder typically surfaces three months into the project as a blocker. Identify them at kickoff, document their use cases, and confirm their availability for design review.

3. Inventory your data sources

List every system that holds customer data, the format it holds it in, and the cadence it can deliver it (real-time stream, hourly batch, nightly export). The integration approach for each source depends on this inventory. Real-time use cases (web personalization, service-agent context) require streaming sources – batch sources cannot drive them.

4. Decide identity resolution rules early

Identity resolution is the heart of every CDP deployment. Decide which attributes you trust as a match (email is high-trust, phone is medium-trust, first-last-name combinations are low-trust without a second factor) and which order you apply them. The rules you set here drive the unified profile quality for every downstream use case. See scandiweb’s deeper treatment of unifying data for omnichannel personalization.

5. Plan the activation channels

A CDP that ingests data without activating it is shelfware. Map every segment to a destination at design time. Marketing Cloud journeys, Commerce Cloud personalization rules, ad-platform audiences, service-agent context cards – each destination needs its own activation contract. For the loyalty-side activation in particular, scandiweb’s Loyalty Program Accelerator is the downstream surface that turns a Data 360 segment into a tiered reward.

6. Set evaluation criteria before go-live

The first 90 days after Data 360 go-live should run against pre-agreed KPIs. Typical examples: time to launch a new audience, share of personalized customer-facing surfaces, lift in repeat-purchase rate on personalized vs control segments, agent handle time with vs without the unified profile.

Salesforce Data 360 vs other CDPs in 2026

The CDP category has consolidated since the Salesforce-Evergage acquisition in 2020. In 2026 the meaningful competitors to Data 360 are Adobe Real-Time CDP, Tealium AudienceStream, Segment (Twilio), and Bloomreach Engagement. The decision is rarely about pure CDP capability – the differentiation lives in which adjacent ecosystem the buyer already runs.

• Choose Data 360 when you already run Salesforce Commerce, Marketing, or Service Cloud – the native integration eliminates the integration tax.
• Choose Adobe Real-Time CDP when your stack centers on Adobe Experience Manager, Adobe Analytics, or Adobe Commerce.
• Choose Tealium or Segment when you need a vendor-neutral CDP that talks to many ecosystems equally.
• Choose Bloomreach Engagement when personalization and search are your primary use cases and CDP is the supporting layer rather than the centerpiece.

For a deeper comparison of personalization tools that sit on top of any of these CDPs, see scandiweb’s 9 best website personalization tools.

Frequently asked questions

Is Salesforce Data Cloud the same as Data 360?

Yes. Salesforce rebranded Data Cloud to Data 360 at Dreamforce 2025 on October 14, 2025. The underlying product, license, integrations, and data model are the same. The rebrand reflects a strategic shift toward the Agentforce 360 platform, not a functional change in the CDP.

Is Salesforce Data 360 a CDP?

Yes. Data 360 (formerly Data Cloud) is a customer data platform built natively into the Salesforce ecosystem. It ingests, unifies, segments, and activates customer data across Salesforce clouds (Commerce, Marketing, Service, Sales) and external channels in real time.

How is Data 360 different from a CRM?

A CRM (like Salesforce Sales Cloud or Service Cloud) stores known customer relationships and interactions. A CDP like Data 360 unifies data from many sources – including the CRM – into a single real-time customer profile that downstream applications can act on. The CRM is one input to the CDP, not a replacement for it.

What does Salesforce Data 360 cost?

Salesforce does not publish standardized public pricing for Data 360. Pricing scales with the number of unified profiles, the volume of data ingested, and the activation destinations enabled. Enterprise deployments typically start in the low six figures annually, with implementation services running 1.5 to 3 times the first-year license. For an accurate quote, engage Salesforce or a partner with current pricing visibility.

How long does a Data 360 implementation take?

A focused Data 360 deployment with two to four data sources and one activation destination ships in 10 to 16 weeks. Enterprise deployments with five or more data sources, complex identity resolution rules, and multiple downstream Salesforce clouds run 4 to 9 months. The variable is rarely the CDP itself – it is the upstream data preparation and the downstream activation contracts.

Can I use Data 360 with non-Salesforce systems?

Yes. Data 360 ingests from any source (web SDKs, S3, Snowflake, BigQuery, Kafka streams, REST APIs) and activates to any destination (ad platforms, third-party email tools, custom storefronts). The native integration is the strongest advantage when you already run Salesforce, but Data 360 is not locked to the Salesforce stack.

What is the difference between Data 360 and Agentforce?

Data 360 is the customer data platform – the live data engine. Agentforce is the AI-agent platform built on top of that data engine. Agentforce agents use Data 360 as their source of truth for customer context. The two products are sold and licensed separately, but the 2026 product roadmap assumes you use them together.

About this guide

Maintained by the scandiweb data and analytics team. Reviewed by Alina Draichuk, Analytics Engineer.

Related reading from the scandiweb blog:

• What is CDP? Guide to customer data platforms for eCommerce
• Läderach Salesforce Data Cloud success story
• How to increase your eCommerce revenue with CDPs
• Unifying data for omnichannel retail personalization
• 9 best website personalization tools

If you are mapping Data 360 against the other CDPs on your shortlist, that comparison is worth doing with someone who has deployed it. Get in touch and we will walk through where Data 360 fits your Salesforce stack – and where it does not.

The post Salesforce Data Cloud Is Now Data 360: A 2026 CDP Guide appeared first on scandiweb.

Why does the purchase event in your Adobe Analytics report suite show 87 orders for yesterday while the Magento (Adobe Commerce) order grid shows 102? That gap is the implementation problem nine out of ten merchants actually have with Adobe Analytics for eCommerce – the platform is correctly capturing what the data layer hands it, and the data layer is not handing it everything. Most setup work since the AEP Web SDK rollout is about closing that gap.

This is the implementation playbook the scandiweb Analytics team runs when a retailer asks why their Adobe Analytics numbers do not reconcile with their order management system, why merchandising eVars are blank, or why migrating from AppMeasurement is harder than the docs make it look. For the definitional version – what Adobe Analytics is, what licensing tiers exist, how it differs from Customer Journey Analytics – the sibling article on what Adobe Analytics is used for is the right starting point. This one assumes you are past that decision and are configuring or fixing the implementation.

Overview

• A working Adobe Analytics eCommerce setup is mostly about the data layer and the seven standard commerce events – not the Analytics UI.
• Merchandising eVars and product strings are where most revenue-attribution gaps sit, because they are easy to declare and easy to break.
• New 2026 implementations should use the AEP Web SDK and XDM for commerce, with a deliberate parallel-run plan against AppMeasurement before cutover.

What an Adobe Analytics eCommerce implementation needs

A retailer-grade Adobe Analytics eCommerce setup has six moving parts: a clean data layer, a tagging library (AEP Web SDK or AppMeasurement), a report suite with the right commerce variables, the seven standard commerce events, merchandising eVars for product-level attribution, and a QA harness that catches breakage on deploy. Get those six right, and the reports take care of themselves.

The pattern we see across Adobe Commerce, Shopify Plus, and headless storefronts is that teams over-invest in the report layer and under-invest in the data layer. Reports cannot fabricate data. If scAdd does not fire on add-to-cart, no Workspace project will show you cart abandonment by product. If the data layer passes a string instead of a number into revenue, Adobe Analytics shows the order but contributes zero to revenue totals. The work is in the layer that the marketing team rarely opens.

For a deeper walkthrough of the install path itself – tag manager choices, data element naming, deployment cadence – see our companion guide on Adobe Analytics implementation steps.

The six things to declare before the first tag fires

1. Report suite ID per environment (production, staging, dev), with timezone matched to the merchant of record.
2. eVar and prop assignments documented in a Solution Design Reference (SDR) – the single artifact that prevents two teams overwriting the same eVar slot.
3. The seven Adobe Analytics standard commerce events: scOpen, scAdd, scRemove, scView, scCheckout, purchase, prodView.
4. Merchandising eVars (typically eVar1–eVar5) flagged for the right binding type – Product Syntax for category, Conversion Variable Syntax for campaigns – and the right allocation model.
5. The products string format: category;productID;quantity;price;events;eVars for every commerce hit.
6. A QA layer (Adobe Experience Platform Debugger plus a CI script that diffs network calls against expected events on the top five user journeys).

Tagging strategy: AEP Web SDK or AppMeasurement?

For new 2026 implementations, the AEP Web SDK is the default. AppMeasurement still works, and Adobe still supports it, but every new feature – including the integration paths that connect Adobe Analytics to Adobe Commerce KPIs and Adobe Journey Optimizer – lands on the Web SDK first. Adobe Experience Platform documentation now treats Web SDK as the recommended path for collecting commerce data (Adobe, May 2026).

The trade-off is real. Web SDK requires XDM schema work upfront – mapping each commerce event into the Adobe Experience XDM ExperienceEvent schema, which adds two to four weeks of analyst time at the start. AppMeasurement gets a basic implementation live faster, but technical debt compounds: every time Adobe rolls out a new Adobe Experience Cloud product, you build a new integration instead of inheriting it from the platform.

When to keep AppMeasurement (for now)

• A stable estate with no Adobe Experience Cloud expansion on the 12-month roadmap.
• A small team without analyst bandwidth to design XDM schemas and run a parallel-tagging window.
• An immediate platform replatform on the horizon – do the AEP migration on the new platform, not the dying one.

When to migrate now

• Activating Adobe Real-Time CDP, Customer Journey Analytics, or Journey Optimizer this year.
• Running multi-brand or multi-region report suites where XDM’s stricter schema enforcement prevents the eVar drift we see in older AppMeasurement implementations.
• Replacing legacy tag manager configurations as part of a broader Adobe Experience Cloud ecosystem rollout.

Designing the report suite for eCommerce

A report suite for a single-storefront retailer is straightforward: one production suite, one staging suite, one rollup if the brand also runs a B2B channel. It gets harder with multi-region, multi-brand, and franchise estates – where the same product catalog runs through different storefronts at different prices, and finance still wants one number for global revenue.

The Adobe Experience League commerce report suite template covers the canonical baseline: timezone, currency, default page settings, and the seven standard commerce events (Adobe Experience League, May 2026). Use it as the starting point, then layer brand-specific decisions on top.

eVar assignments that age well

The merchandising eVars (the ones that capture product-level attribution) are where most implementations break in year two. Reserve at minimum:

• eVar1 – Product category (Product Syntax binding, Last Touch allocation).
• eVar2 – Internal search term (Conversion Variable Syntax, Most Recent allocation).
• eVar3 – Campaign / channel (Conversion Variable Syntax, Linear allocation if you run a multi-touch attribution model).
• eVar4 – Customer segment / cohort (Visit expiration).
• eVar5 – Promotion or coupon code (Conversion Variable Syntax, Most Recent allocation).

Document the binding type and allocation model in the SDR. The most common bug we audit is two analysts independently re-purposing eVar3 for two different campaigns six months apart – at which point the data behind every paid-channel ROI report is silently corrupted.

The purchase event and the data layer

The purchase event is the single most important commerce event and the one that gets implementation wrong the most often. A correct purchase hit contains:

• events=purchase plus events=event1 if you track first-time buyer separately.
• The products string with category, product ID, quantity, price, the same purchase event repeated per line, and merchandising eVar values.
• The order ID, currency, tax, and delivery cost in their own data elements (often binding into eVar6 and eVar7, plus the appropriate currencyCode in XDM).

The three failure modes scandiweb sees across audits:

1. Duplicate purchase hits – the data layer fires on the order confirmation page AND on a return-to-page refresh. Fix: dedupe on purchaseID in the tagging library, not in the report suite.
2. Missing tax and delivery-cost breakouts – revenue arrives, but finance cannot reconcile to the ERP because tax is bundled into the currencyCode total. Fix: declare tax and delivery cost as discrete numeric data elements before launch, not after the first finance complaint.
3. String-typed revenue – the data layer hands over "129.95" instead of 129.95, and Adobe Analytics silently coerces or drops it depending on the SDK version. Fix: cast numbers explicitly in the data layer. Never assume the back end will send the right type.

How do you set up Adobe Analytics for an eCommerce site?

Setting up Adobe Analytics for an eCommerce site is a five-step sequence: build a clean data layer, install the AEP Web SDK or AppMeasurement, create a report suite from the commerce template, configure the seven standard commerce events plus merchandising eVars, and validate every event with the Adobe Experience Platform Debugger before declaring the implementation live.

The work that is invisible in that summary is the data layer. A clean data layer is a JSON object available on every page that names the event (page, productView, cartAdd, purchase, etc.), describes the page or product or cart contents in stable property names, and is populated by the back end before the tag manager reads it. Without that contract between the back end and the tag manager, the frontend tag fires on stale or partial data, and every downstream report inherits the mistake.

A practical five-day implementation cadence

• Day 1 – SDR review and data-layer specification. Sign-off between engineering, analytics, and marketing on event names and properties.
• Day 2 – Backend implementation of the data layer on cart, checkout, and order confirmation pages.
• Day 3 – Tag manager configuration in staging (Adobe Experience Platform Data Collection or Adobe Launch). For more on tag library options, see Adobe Launch tag management.
• Day 4 – Test plan execution: 20+ scripted journeys covering catalog browse, add-to-cart, abandonment, guest checkout, logged-in checkout, and refund.
• Day 5 – Production cutover with a parallel-tagging window if the old AppMeasurement install stays live for reconciliation.

Analysis Workspace for eCommerce: the four reports that earn their keep

A retailer team that opens Analysis Workspace daily uses four projects, not forty. Build these first and ignore the temptation to roll out a dashboard of vanity metrics.

1. Purchase funnel with fallout

Steps: prodView → scAdd → scCheckout → purchase. Visualize as a fallout report segmented by device, by traffic source, and by new vs returning. The fallout step that loses the most users is the page that earns the next CRO test – not the page with the most traffic.

2. Product contribution analysis

For any spike or dip in conversion, run Workspace’s Contribution Analysis on the purchase event grouped by product, category, and campaign. It surfaces which dimension value moved the metric the most. Pair this with Adobe Target and GA4 integration when the spike traces back to a personalization test.

3. Cart abandonment cohort

A weekly cohort of users who hit scAdd but not purchase within 7 days, segmented by category and price band. Feed the cohort into Adobe Journey Optimizer or your ESP for triggered emails.

4. Revenue attribution by channel

A flow visualization from the first-touch channel to the converting channel, weighted by your allocation model. This is where the Linear vs Last Touch vs Algorithmic decision shows up – which is why the eVar3 allocation choice in the SDR matters so much.

Common Adobe Analytics eCommerce pitfalls (and how the scandiweb Analytics team handles them)

The patterns repeat across the merchants we audit. None of them is mysterious, and all of them are preventable.

• Two report suites with the same name. Multi-region rollouts create staging suites that copy production names with a -staging suffix and then drift apart. Fix: a documented suite naming convention enforced in the SDR.
• Data-layer values that exist on staging but not production. The product team tests in staging, where the data layer is enriched. Production goes out without the same enrichment. Fix: data-layer regression tests run on every release.
• Merchandising eVars filled by the front end instead of the back end. Frontend-populated eVars break the moment a third-party script changes load order. Fix: backend-rendered data layer, always.
• Tag manager rules duplicating events. Two analysts add two rules that both fire scAdd. Cart additions double. Fix: a single ownership matrix for tag manager rules and a code review step before publishing.
• No DataWarehouse exports. Finance asks for raw transaction data and the team has no way to pull it. Fix: schedule DataWarehouse exports to S3 weekly from Day 1.

scandiweb has delivered Adobe Commerce and Magento (Adobe Commerce) projects with full Adobe Analytics implementations for retailers across apparel, electronics, and grocery since opening in 2003 – more than 2,100 eCommerce projects in total. The pitfalls above are the ones that recur on the technical-audit calls we run before quoting an analytics fix.

How is Adobe Analytics different from Google Analytics 4 for eCommerce?

For eCommerce specifically, Adobe Analytics gives you deeper product-level attribution through merchandising eVars and richer Workspace analysis (fallout, contribution, cohort). Google Analytics 4 gives you a free entry point, native BigQuery export, and tight Google Ads integration. The choice is rarely about features – it is about whether your team has the analyst depth to use Adobe’s flexibility without breaking it.

That is the lighter take. For a fuller comparative breakdown, including pricing, look at the sibling guide on Adobe Analytics pricing tiers and the definitional companion on what Adobe Analytics is used for. For most enterprise retailers running Adobe Commerce already, Adobe Analytics removes a procurement conversation – the licensing slot is open, and the integration with Adobe Real-Time CDP and Adobe Target removes the data-stitching overhead that GA4-plus-third-party-CDP stacks add.

Migrating from AppMeasurement to the AEP Web SDK

The migration is a four-stage program, not a tag swap. Stage 1 is XDM schema design – mapping every existing eVar, prop, and event into the XDM ExperienceEvent schema with commerce extensions. Stage 2 is parallel implementation – both libraries running side by side, writing to two separate report suites or two separate datasets. Stage 3 is reconciliation – running daily diffs on the top metrics until the variance is within 1%. Stage 4 is cutover and AppMeasurement removal.

The reconciliation step is where most projects stall. Variances above 5% almost always trace to one of three causes: timing differences in how the two libraries flush hits, schema-mapping errors where a data element was renamed but not re-bound, or sampling differences in cases where one library lazy-loaded and the other did not. Plan for two to four weeks of reconciliation, not one. The Adobe Experience League integration documentation between Adobe Commerce and Adobe Analytics has the canonical mapping for product, cart, and order data (Adobe Experience League, April 2026).

For retailers also running content-driven storefronts, the same migration logic applies to the Adobe Experience Manager for the eCommerce layer, where the data layer often spans multiple delivery channels.

Why is my Adobe Analytics revenue number different from my order management system?

Almost always a data-layer issue, not an Adobe Analytics issue. The four most common causes are duplicate purchase hits (refresh on confirmation page), missing or mis-typed revenue values (string instead of number), refund handling not subtracting from the original order, and a timezone mismatch between the report suite and the order management system. Audit those four before assuming the report suite is wrong.

The harder cases involve guest-checkout users hitting Adobe Analytics from a different domain than the order placement endpoint, or PCI-compliant checkout flows that block the SDK on the final confirmation page. Both are solvable, but both require a server-side hit to recover the conversion – Adobe’s Server-Side Forwarding or a direct Adobe Experience Platform Edge Network call from the order management system on order create.

Use cases that move the needle for eCommerce teams

A properly implemented Adobe Analytics for eCommerce setup is the data substrate for personalization, retention, and merchandising decisions. The four use cases retailers come back to:

• Cart abandonment recovery – cohort exports feeding a triggered email or Adobe Journey Optimizer flow.
• Product affinity for merchandising – Workspace’s Item dimension on prodView segmented by category to surface cross-sell pairs.
• CRO test triage – fallout reports identifying the highest-loss step before any test brief gets written. Pair with our Conversion Rate Optimization work for an end-to-end CRO program.
• Adobe-derived industry benchmarks – Adobe’s Digital Economy Index publishes monthly US online consumer transaction trends derived from Adobe Analytics data (Adobe Business, 2026), useful for sizing a brand’s performance against the wider market without licensing third-party panel data.

When Adobe Product Analytics fits alongside Adobe Analytics

Adobe Product Analytics is the newer product-led-growth sibling to Adobe Analytics. For eCommerce specifically, Adobe positions it as the surface for “real shopper behavior into growth – timing, intent, and triggers made actionable” (Adobe for Business, September 2025). The practical division: Adobe Analytics is still the system of record for revenue, channel attribution, and funnel reports. Adobe Product Analytics is the exploration layer for behavioral cohort discovery without writing SQL.

Most retailers do not need both yet. Implement Adobe Analytics correctly first, then layer Product Analytics on the same XDM dataset when the analyst team has the bandwidth to use exploration tools that are not pre-built dashboards.

FAQ

What are the seven standard commerce events in Adobe Analytics?

The seven standard Adobe Analytics commerce events are scOpen (cart opened), scAdd (item added to cart), scRemove (item removed), scView (cart viewed), scCheckout (checkout started), purchase (order placed), and prodView (product detail viewed). They anchor every commerce report and every Workspace funnel. Declare all seven before launch, even if you only need three on Day 1.

Do I need to use eVars for product attribution in Adobe Analytics for eCommerce?

Yes. Merchandising eVars are how Adobe Analytics ties a conversion event back to the specific product or category that earned it. Without merchandising eVars configured correctly (binding type plus allocation model), revenue still arrives in reports, but you cannot break it down by product, category, or campaign, which makes most eCommerce decisions impossible.

Can Adobe Analytics replace my order management system for revenue reporting?

No. Adobe Analytics is the source of behavioral revenue – revenue attributable to traffic, channels, and campaigns. The order management system is the source of accounting revenue – revenue net of refunds, returns, and chargebacks. The two should reconcile within 1–2%, and they should never replace each other.

How long does an Adobe Analytics eCommerce implementation take?

A clean implementation on a single-storefront site with an existing data layer takes two to three weeks of analyst plus engineering time. A multi-brand, multi-region implementation or an AppMeasurement-to-AEP Web SDK migration takes six to twelve weeks, with most of the time spent on schema design and reconciliation, not on tagging itself.

Should I migrate to the AEP Web SDK now or wait?

Migrate now if you are activating any other Adobe Experience Cloud product this year (Real-Time CDP, Journey Optimizer, Customer Journey Analytics). Wait if the estate is stable, the analyst team is small, or a platform replatform is on the 12-month roadmap – in which case, do the AEP work on the new platform.

What is the most common Adobe Analytics eCommerce implementation bug?

The most common bug is a purchase event that does not reconcile to the order management system, caused by a data-layer issue – usually a duplicate hit on confirmation-page refresh or a string-typed revenue value the SDK does not parse correctly. Audit the four data-layer causes (duplicate, type, refunds, timezone) before changing any Adobe Analytics configuration.

Is Adobe Analytics worth it for a mid-market eCommerce retailer?

For retailers already on Adobe Commerce or planning a move into Adobe Experience Cloud (Real-Time CDP, Target, Journey Optimizer), Adobe Analytics removes a procurement and integration conversation. For standalone Shopify or BigCommerce retailers without other Adobe products, Google Analytics 4 plus a third-party CDP is usually a more proportionate spend.

Decide whether your Adobe Analytics setup is closing the gap between behavioral revenue and your order management system, or quietly widening it. Book an Adobe Analytics audit and the scandiweb Analytics team will work through the data layer, the eVar map, and the AEP migration plan with your engineering and marketing leads.

The post Adobe Analytics for eCommerce: An Implementation Playbook for Online Retailers appeared first on scandiweb.

Most posts about google analytics 4 benefits read like a feature inventory: 22 capabilities listed flat, ranked by no one. The real question analytics owners have is different. Which features change the way a team measures, and which ones look impressive in a deck and then sit untouched for a year? This piece sorts the 10 that pull their weight, with the limits, eligibility thresholds, and quota math that most lists quietly skip.

Universal Analytics stopped processing data on July 1, 2023 (Google Help). Standard GA4 properties have been the only Google Analytics for nearly three years, so the operational questions have shifted: less “should we migrate,” more “are we using the engagement model, the BigQuery export, and the predictive audiences in a way that improves a single decision.” scandiweb runs GA4 as a Google Premier Partner across 2,100+ eCommerce projects delivered, including a Looker Studio + BigQuery setup that saved one merchant €135,000 annually versus a GA360 contract. The benefits below are framed in that operational light.

Overview

• GA4’s event-based model, engagement metric, and BigQuery export are the three features that genuinely change a measurement workflow. The rest are useful but secondary.
• Predictive metrics need 1,000+ qualifying users in the last 28 days to activate, and standard data retention defaults to 2 months unless BigQuery is set up.
• Honest limits matter. Explorations can sample over 10M events, default retention is short, and the API quotas bite fast when reporting scales.

1. Engaged sessions and the engagement rate (the metric that replaced bounce rate)

The engaged session is GA4’s headline behavioral change. A session counts as “engaged” if it lasts at least 10 seconds, fires at least one conversion event, or includes at least two pageviews or screenviews (Google Help). Engagement rate is the percentage of sessions that meet one of those three. Bounce rate, in GA4, is its inverse.

Why this matters: in Universal Analytics, a “bounce” was any single-page session, no matter how long the visitor stayed. An eight-minute read that ended in a tab close was indistinguishable from a misclick. GA4’s engaged session reads that visit correctly. Teams comparing GA4 against archived UA numbers should expect engagement rate to land roughly where 1 minus bounce rate did, but the meaning is closer to what they actually wanted to measure.

For our own blog reporting, the engagement-rate switch cut “false bounces” on long-form articles by roughly a third versus the legacy UA metric, which mostly meant the SEO team stopped chasing a number that was never the right one.

2. The event-based data model (everything is an event)

GA4 replaced UA’s session-and-pageview model with a flat event model. A pageview is page_view. A purchase is purchase. A button click is an event you name, with the parameters you choose. There is no hit limit per session because there are no sessions in the schema, just session_start events the system reconstructs at query time.

The practical payoff: any interaction the website or app can fire (a 25%-watch video, a quote-form submit, an add-to-cart variant) becomes a first-class entity that can be turned into a conversion, a custom dimension, or a BigQuery row, without coding around a hit-count cap. The old UA 10M-hits-per-property ceiling is gone.

The friction is at the implementation end. A well-instrumented GA4 needs an event-naming convention that survives a year of marketing experiments. Inconsistent event names (“Add to Cart” vs add_to_cart vs AddToCart) are the single most common reason a GA4 audit finds the data unusable.

3. Cross-device and cross-platform tracking (web + app in one property)

GA4 properties unify web (gtag) and app (Firebase) data inside one property. A user who reads on desktop, browses on mobile web, and buys in the iOS app shows up as one journey, provided GA4 has a User-ID or Google Signals to stitch them. Before GA4, this needed manual data joins or a paid GA360 license.

The honest part: identity stitching is only as good as the signals it has. A strong logged-in customer base resolves most journeys via User-ID. If most visitors are anonymous and Consent Mode v2 is denying analytics_storage, GA4 falls back to modeled data, useful, but a model, not a measurement. Treat cross-device numbers as directional unless you can show what fraction of sessions carried a User-ID.

4. BigQuery export (the feature that decides whether a GA4 is mature)

The BigQuery export was the headline payoff of GA4 from day one. Every standard property can stream raw, event-level, unsampled data into a Google Cloud project. Under GA360 this was a five- or six-figure annual line item. In GA4 it sits inside the free tier, subject to BigQuery’s own pricing: 10 GB of active storage and 1 TB of on-demand query data per month at no charge (Google Cloud BigQuery pricing).

The operational truth: for a high-traffic eCommerce property, the 1 TB query allowance fills quickly once a few dashboards run scheduled queries. The merchant case study linked in the intro came in around €4,000 a year all-in for the full GA4 + BigQuery + Looker Studio stack, with cost dominated by storage, not query.

For teams hitting GA4’s API rate limits in Looker Studio, our GA4 API quota breakdown covers moving the heavy lifting into BigQuery.

5. Predictive metrics and predictive audiences

GA4 ships three predictive metrics from Google’s machine-learning models: purchase probability (chance a user active in the last 28 days buys in the next 7), churn probability (chance a user active in the last 7 days goes inactive in the next 7), and predicted revenue (expected 28-day revenue from an active user). Each can be turned into a predictive audience and pushed into Google Ads (Google Help).

The eligibility thresholds are what most listicles skip. A predictive metric only activates if, over the prior 28 days, at least 1,000 returning users triggered the relevant predictive event (purchase or in_app_purchase for purchase models, any user-engagement signal for churn), with at least 1,000 users not triggering it. Properties under that traffic threshold see “insufficient data” and nothing else. Most failed predictive audiences are not a setup bug, just a volume floor.

For merchants over the threshold, predictive audiences run hot. Our PPC team has used purchase-probability audiences to weight Google Ads bidding on a fashion merchant’s account and recorded a roughly 30% lift in conversion rate on the predictive segment, with spend reallocated rather than added.

6. Native integrations with Google Ads, Search Console, BigQuery, and Looker Studio

GA4’s native integration set is more usable than UA’s was. Google Ads audiences sync both ways. Search Console surfaces organic queries inside GA4’s Acquisition reports. BigQuery is the export hub. Looker Studio reads GA4 through the dedicated connector or, for any non-trivial dashboard, through BigQuery for speed and quota relief.

The integration most under-used in practice is the Search Console one. Two clicks to enable, and query-level organic data appears alongside the rest of acquisition: useful for any content team historically living in a separate tab for organic. The dashboard we built around this for an apparel merchant is documented in the Looker Studio migration case, which also covers the BigQuery-routed pattern that keeps the GA4 API quota off the critical path.

7. Intelligent tracking with Consent Mode and behavioral modeling

GDPR, ePrivacy, and parallel rules in California, Brazil, and the UK have made cookie-only tracking a dead-end. GA4’s answer is Consent Mode v2 plus behavioral modeling. When a visitor denies analytics_storage, GA4 still records anonymous, modeled signals (no client_id, no cross-session join) and uses machine-learning to estimate the behavior of the consented population on top.

What this means in practice: a GA4 property with Consent Mode v2 set up and modeling enabled does not see the hard drop in measured conversions that UA properties hit the day a cookie banner went live. The modeled data is not perfect, but it closes the difference between a 20-30% measurement gap and an indefensible one. For merchants in the EU, getting Consent Mode v2 right is now table stakes. The CMP and signals need correct implementation before modeling can do its job.

8. Free advanced analysis – explorations

The exploration suite (path, funnel, segment overlap, cohort, user lifetime, free-form) is GA4’s answer to what was previously GA360-only Analysis Hub. Every standard property can build ad-hoc funnels, see the most common paths between any two events, or compare segment overlaps without a paid tier.

The exploration that pays for itself first is the funnel. A 4- or 5-step funnel from product view to purchase, with drop-off rates per step, tells a merchant where the leak is in 30 seconds. Path exploration, in contrast, is interesting to look at and rarely changes a decision unless used surgically.

The quirk worth flagging: explorations sample for very high event counts. A property with more than ~10M events in the chosen date range will show a yellow shield icon and a sampled result. Standard reports, by contrast, are unsampled. If the number matters for a budget call, run it in standard reports or BigQuery.

9. Retention reports and user lifetime

GA4 ships first-class retention and cohort reports out of the box. The retention report shows how returning users behave over the 42 days following acquisition. The user-lifetime exploration shows LTV and engagement curves by acquisition source, campaign, or audience.

These are the reports most marketing teams forget exist. A weekly look at retention by acquisition channel often separates the channels that buy revenue from the channels that buy customers, and the gap is often counter-intuitive. Paid social often ranks high on first purchase and low on 30-day retention. Organic search and email tend to do the opposite.

10. Data-retention controls plus a privacy-first default

GA4 lets the admin set event data retention to 2 months or 14 months in the property settings (Google Help). The default is 2 months. After the window expires, event-level data is purged from the interface (aggregated counts remain, but no event-level explorations against expired data).

The 2-month default is the single thing that catches most teams off-guard in year one. A team running a quarterly review in month four cannot pull event-level audiences against month one’s data unless retention was raised to 14 months on day one, and 14 months is the maximum GA4 offers. For anything beyond that, BigQuery export is the only durable answer, which is why BigQuery sits at #4 on this list rather than as a nice-to-have.

For a deeper read on the pattern, see how to overcome GA4 API limits.

Where GA4 still bites: the honest limitations

GA4 is the only Google Analytics now, but it is not free of friction. The five things teams should plan around:

1. API quotas hit faster than expected. The GA4 Data API’s per-property and per-project quotas (concurrent requests, tokens per hour, tokens per day) can be exhausted by a moderately complex Looker Studio dashboard. Standard fix: push heavy queries into BigQuery.
2. Explorations sample on large date ranges. Over ~10M events in the window, the result is sampled. Standard reports and BigQuery are not. For budget decisions, do not pull from a sampled exploration.
3. Data retention is short by default. Two months standard, 14 months maximum in the UI. Anything beyond that needs BigQuery export from day one.
4. Identity stitching is signal-dependent. Without User-ID or Google Signals, cross-device journeys are modeled. The model is reasonable but it is a model.
5. The interface still has rough edges. Some reports load slower than UA equivalents, the custom-report builder is more capable but less intuitive, and teams new to GA4 typically need 4-6 weeks before the muscle memory catches up.

What is the biggest benefit of Google Analytics 4 versus Universal Analytics?

The single biggest benefit is the unsampled, event-level data warehouse GA4 makes accessible through BigQuery on the free tier. Under UA, raw event-level data was a GA360 feature with a five- or six-figure annual price tag. In GA4, every standard property streams it for free, subject to BigQuery’s own usage pricing. Engagement rate, predictive audiences, and cross-platform tracking all flow from that change.

How long does GA4 store data, and why does it matter?

GA4 stores event-level data for 2 months by default and up to 14 months if the admin raises the retention setting in property administration. After the window, data is purged from the GA4 interface, though aggregated counts in standard reports remain. For year-over-year, cohort, or customer-lifetime analysis past 14 months, BigQuery export from day one is the only durable answer.

Is Google Analytics 4 free, and where do the costs actually come from?

GA4 itself is free under the standard usage limits. Costs appear in two places: BigQuery (storage and query, beyond the 10 GB and 1 TB monthly free tiers), and the human time to instrument events well. Most eCommerce merchants land between €1,500 and €6,000 a year all-in for the GA4 + BigQuery + Looker Studio stack, a small fraction of what GA360 cost for the same data depth.

FAQ

Is GA4 replacing Universal Analytics?

GA4 replaced Universal Analytics on July 1, 2023, when standard UA properties stopped processing data. GA360 UA properties followed on July 1, 2024. Existing UA reports are no longer accessible in the Google Analytics interface, so GA4 is the only Google Analytics for any merchant running it today.

What is the difference between Google Analytics 4 and Universal Analytics?

GA4 uses an event-based data model and unifies web and app data in one property, where UA used a session-and-pageview model and tracked them separately. GA4 also ships free BigQuery export, predictive metrics, and a privacy-first identity model, none of which UA offered on standard properties.

How many users does a property need to activate predictive audiences in GA4?

Predictive metrics activate once a property has at least 1,000 returning users who triggered the relevant predictive event (and 1,000 who did not) in the prior 28 days. Properties under that volume see “insufficient data.” This is the most common reason small-merchant predictive audiences fail to populate.

Can GA4 be used without cookies?

GA4 with Consent Mode v2 records modeled, anonymous signals when a visitor denies analytics_storage. The data is modeled rather than measured, but the modeling closes most of the measurement gap that cookie-banner deployments otherwise create. The CMP setup needs to be correct before modeling can do its job.

What is an engaged session in GA4?

An engaged session lasts at least 10 seconds, fires at least one conversion event, or includes at least two pageviews or screenviews. Engagement rate is the share of sessions meeting one of those three, and is GA4’s replacement for UA’s bounce rate.

Does GA4 sample data?

Standard reports are not sampled. Explorations are sampled once a date range covers more than ~10 million events. BigQuery export is never sampled. For a budget or campaign decision, run the number from standard reports or BigQuery, not from a sampled exploration.

How do I avoid hitting GA4 API quota limits in Looker Studio?

Route heavy reporting through BigQuery rather than the GA4 Data API directly. Looker Studio reads from the BigQuery export, which has no per-property GA4 quota and runs faster.

Sorting which GA4 features actually move a measurement workflow is a different exercise from listing them. If you want a clear-eyed read on which features are pulling weight in your property today, and which ones look impressive in a dashboard and then sit untouched, book a GA4 audit with the scandiweb analytics team.

The post Google Analytics 4 Benefits: 10 Features Worth Knowing in 2026 appeared first on scandiweb.

When B2B eCommerce platforms become too customized to upgrade, they stop being assets and start becoming blockers. Over time, even once well-functioning systems can become hard to maintain and risky to scale. We often see this in long-running Magento 1 setups, where there is no clear path to upgrade and rising concerns around security and compliance.

Cook Medical needed a platform that could handle the complexity of selling medical devices without making it feel complex. We partnered to rebuild the entire experience on Magento 2, introducing a modern, stable interface with minimal customization, seamless ERP integration, and a new analytics foundation to help internal teams understand how the store was being used.

About

Cook Medical is a family-owned and globally recognized manufacturer that supplies hospitals and healthcare providers with medical devices used in minimally invasive procedures, with a product catalog of more than 15,000 items across various specialties.

Their eCommerce platform isn’t public-facing. Access is restricted by user role, and buyers can only view and purchase products tied to their specific clinical division. That level of control is essential in regulated environments, but it also adds complexity.

Cook Medical’s Magento 1 site had become difficult to maintain and technically fragile. It had reached a point where maintenance and upgrades were no longer practical – years of deep customization made it impossible to upgrade without risking instability or security gaps. The main objective of the migration was to reduce custom code for a cleaner, maintainable Magento 2 setup that could be easily updated and kept secure.

Additionally, limited visibility into product data meant teams couldn’t easily track what users were doing or what they needed.

Project goals

The move to Magento 2 was driven by the need to create a stable foundation, one that would be secure, easier to maintain, and ready for future growth. Key project objectives:

• Rebuild the storefront on Magento 2 with minimal customization to simplify future upgrades
• Migrate 15,000 SKUs and historical data from Magento 1 to Magento 2
• Maintain strict security standards across all system components
• Integrate with SnapLogic middleware for ERP and order data sync
• Preserve strict access rules across medical divisions with role-based permissions
• Make pricing and availability visible at the product listing level
• Introduce site-wide behavior tracking with GA4 and a compliant consent setup
• Improve mobile usability.

Approach

Rebuilding the platform around user needs

Cook Medical’s new Magento 2 site was built using the Luma theme as a base. While Luma isn’t known for cutting-edge visuals, our priority here was usability and making it faster and easier for verified buyers to find the right products, check pricing, and complete transactions.

To simplify the product discovery experience, we introduced:

• Price visibility directly on product listing pages (PLPs), instead of hiding pricing behind requests
• Cleaner navigation and improved mobile responsiveness
• A mandatory verification step at login to ensure that only authorized users could proceed.

Because the storefront is gated and access is restricted based on medical specialty, we worked closely with Cook Medical to preserve their internal logic while improving the interface. For example, cardiology buyers can’t see urology products, and vice versa; permissions cascade accordingly. This access control was retained and restructured for Magento 2.

Throughout the project, we prioritized security and maintainability, minimizing customization and relying on Magento’s native capabilities wherever possible. We created a platform that can be easily patched and upgraded, which is an essential factor for a company operating in a regulated industry.

ERP integration

One of the project’s biggest technical requirements was the integration with SnapLogic, Cook Medical’s chosen ERP middleware. At the start of the project, no functional API was in place, and the scope of integration was still evolving. Before development, we stepped in to support planning, helping the client define what data needed to flow, how, and where.

Our team handled:

• Designing a new SnapLogic API to receive order data from Magento 2
• Enabling SnapLogic to use Magento’s REST API to retrieve user, product, and category data
• Building integration logic to support data flow between Magento 2 and SnapLogic in both directions
• Advising on endpoint structure, parameter requirements, and process sequencing.

The only payment integration required was CardConnect, which we configured to align with Cook Medical’s internal payment handling process.

Analytics setup with GA4

Before the migration, Cook Medical had no analytics framework in place. We began by implementing the WeltPixel dataLayer module, configuring it to track key eCommerce events such as product views, add-to-cart actions, checkout progress, and completed purchases. This allowed us to send structured event data to a newly created Google Analytics 4 property via Google Tag Manager (GTM).

To support Cook Medical’s reporting, we extended the default dataLayer with additional product-specific parameters, including:

• clinical_specialties
• product_type
• reference_part_number
• order_number
• gtin

Other marketing data, such as traffic source, new vs. returning user, average engagement time on the website, approximate visiting location, and tech details such as the browser used for the visit or the device type, are automatically collected by GA4. Ultimately, we consolidated the web behavior & marketing data into one place for better decision-making.

To meet data privacy requirements, we also integrated Cookiebot CMP (Consent Management Platform), allowing users to manage consent preferences while ensuring that tracking scripts only fire after consent is given, which is an essential requirement for global compliance.

Cook Medical now has a robust, compliant, and highly configurable analytics foundation. With GA4 and GTM in place, they have complete visibility into how users interact with the platform, what content drives engagement, areas for improvement, and other insights.

Results

The rebuilt Magento 2 store gives Cook Medical’s internal teams and B2B customers a much clearer and more structured experience. Search performance and product discovery were central to the project’s success. With pricing and availability visible on listing pages and by optimizing navigation for verified users, the site became easier to use and more aligned with how their target buyers place orders.

The new setup is lighter, easier to maintain, and keeps Cook Medical’s digital operations secure and upgrade‑ready.

Customer feedback has been positive, particularly around the improved visibility of key product data. What previously required a manual request or a call can now be completed directly through the interface, without compromising access controls or clinical boundaries.

Project outcomes

• 15,000+ SKUs successfully migrated from Magento 1
• Custom ERP integration delivered and validated via SnapLogic
• Full GA4 analytics implementation with detailed product-level tracking
• Role-based permissions restructured and preserved in Magento 2
• Clean, responsive interface now accessible across devices
• Site launched on schedule over a weekend to avoid disruption, and described by the client as their smoothest launch to date
• Stable, secure, and future‑proofed platform.

Cook Medical has also kicked off a new initiative to integrate Magento 2 with Oracle ERP, expanding the platform’s role in enterprise operations.

Ready to modernize your B2B eCommerce experience? If you’re working with legacy systems or a catalog that demands precision, we’re the team to have by your side. Reach out to scandiweb today, and let’s build a platform that’s functional and easy to use for your team and your customers.

The post Case Study: Dated Magento 1 Migration to a Modern Magento 2 Experience for B2B Buyers appeared first on scandiweb.

Working with scandiweb has been a really good experience. They were key in our recent project to migrate our Looker Studio dashboards from Universal Analytics to GA4, which included complex product stat tracking. They not only provided us with clear options throughout the process but were also instrumental in helping us understand and fix several underlying tracking issues. Their expertise and efficiency made the entire migration smooth and successful.

Thanks to all the team!:)

Gisela Morinigo
Open Data Product Manager at Global Fishing Watch

When Google announced the end of Universal Analytics (the platform was shut down on July 1, 2024), organizations across every industry were forced to rethink their analytics setups. For many, the transition to Google Analytics 4 (GA4) raised questions like “how to maintain reporting continuity?, “what to do with years of custom dashboards?” 

Global Fishing Watch faced these same questions, but their needs weren’t typical. As a nonprofit working to increase transparency on the oceans, their team depends on accurate web and product analytics to support research, policy, and public awareness. We partnered with them to replicate and enhance their business intelligence (BI) setup and ensure it reflects the complexity of their work and supports the people using that data every day.

About 

Global Fishing Watch is a nonprofit organization that uses technology to shine light on what’s happening in our oceans, helping create a more transparent and sustainable future for marine life. By tracking fishing vessels and making maritime data publicly accessible, they support efforts to protect marine ecosystems, combat illegal and unreported fishing, inform better policy decisions, and accelerate ocean governance.

With oceans under increasing pressure, their platform is widely used to understand fishing activity in real time. We felt especially proud to support Global Fishing Watch because their mission extends far beyond data toward creating accountability on the water and giving governments, researchers, organizations, and communities the tools they need to safeguard our oceans for generations to come.

Supporting this mission are several public-facing products:

• Map – an interactive platform to visualize and analyze global fishing activity
• Marine Manager – tools to monitor and manage marine protected areas
• Carrier Vessel Portal – data on transshipment activity and carrier vessels
• Vessel Viewer – detailed insights on individual vessel activity
• Data Download Portal – open access to downloadable datasets for research and analysis.
• API Portal – allows to explore, visualize, and freely download Global Fishing Watch data to transform global collaboration and catalyze solutions for complex ocean problems.

Reliable data operations are critical for a mission built on ocean accountability and open access. With the sunset of Universal Analytics (UA), GA4 migration was all about keeping essential information flowing to those working to protect the ocean.

Project goals

Global Fishing Watch had an extensive reporting setup built on UA, with dashboards blending web analytics and backend product data. Their team needed a solution that could replicate and enhance the setup while relying on good-quality data.

Main project goals:

• Conduct a comprehensive audit of the existing tracking and data collection
• Fix legacy issues and set up GA4 using current best practices
• Rebuild UA dashboards with the GA4 data and improve the existing BI dashboards
• Support the internal team during and after the transition to GA4.

Our priority was building a more flexible and future-proof BI setup that could grow with the organization’s needs.

Approach

Global Fishing Watch had multiple data dependencies across products, platforms, and teams. A successful transition meant carefully auditing what was already in place and designing a reporting setup that would remain stable and usable long after Universal Analytics was gone. Let’s look at each of the project stages in the following sections.

Data quality assurance and improvements

The insights are as good as the quality of data. Before rebuilding any dashboards, we performed an audit and made improvements to the tracking setup.

• GA4 property review
  • We began with a property-level audit of the GA4 setup to check for configuration issues and gaps in data collection. 
  • Based on the audit, we reconfigured GA4 settings to follow current best practices and resolved issues affecting reporting accuracy.
• Google Tag Manager (GTM) audit and cleanup
  • Since Universal Analytics was being phased out, we removed outdated tags and refined the GTM setup to ensure the best level of data governance.
• Custom dataLayer event development
  • We gathered requirements for meaningful user interactions across Global Fishing Watch product pages. These were then implemented as structured dataLayer events to support more granular and relevant reporting in GA4.

Building customized dashboards in Looker Studio

With the data layer improved and GA4 properly configured, we proceeded to rebuild the dashboards. The dashboards relied on the GA4 linked directly to BigQuery, along with backend system data exported to the same warehouse via custom pipelines.

Preparing the data

Query composition

Universal Analytics connected natively to Looker Studio with no quota limits, i.e., the Wild West era of dashboards. GA4, on the other hand, introduced strict limits that kick in with heavy querying, especially with large date ranges, multiple users, or complex filters.

Also read:
How to Overcome GA4 API Limits and Save on Costs
GA4 API Quota Apocalypse and How to Survive It
Note – the limits since then have become much less strict, but you’ll still find our tips above useful!

To bypass these restrictions, we used GA4’s raw BigQuery export. Since this raw data requires additional processing, we built transformation queries to output clean data into dedicated reporting tables. Another data source used in the project was data from the operational system.

Cost control improvement

Google Cloud’s pay-as-you-go model charges for all resource usage. We initially used views for faster development, but needed cost optimization as the project matured.

Key optimizations:

• Switch from views to tables – the biggest cost reduction
• Implement custom upsert logic – daily updates instead of full GA4 re-processing
• Add partitioning and clustering for more efficient queries.

What was once a daily cost during peak usage became the total monthly cost. Proper implementation made a clear difference in how the data pipeline impacted the budget.

Dashboard setup

The dashboard was designed with its key audiences in mind. It consists of aggregated-level pages and product-specific dashboards. On top of that, an executive overview page highlights the most important metrics and timelines for leadership.

Customizations

1. Brand guidelines
   • We styled the dashboard using Global Fishing Watch’s brand guidelines (colors, fonts, icons) to ensure consistency with the company’s visual identity.
2. Product milestones
   • Sometimes you notice a data change but can’t immediately tell whether it’s expected or tied to a product update. To solve this, we embedded a Google Sheet that logs major deployments and changes.

3. Dashboard usage guides
   • Not all user groups are equally familiar with BI tools, and that’s okay. To make the dashboard easier to navigate, we added a built-in guide that walks users through the report’s main and hidden functionalities.
4. Glossary
   • Some teams work less frequently with web analytics. To make interpretation easier, we created a glossary page explaining how key metrics are calculated and what each data source represents.

5. Filtering internal staff
   • We added a simple button that allows users to filter out traffic from Global Fishing Watch employee accounts. Buttons are often underused in Looker Studio!

Summary of dashboard specifics

1. Multiple dashboard sections for different stakeholder groups
2. KPI glossary and dashboard usage guidelines
3. Embedded sheet with product deployment context
4. Styling according to brand guidelines
5. Ability to exclude internal traffic.

Solution architecture

Below is the final solution architecture, which illustrates how data moves from collection to visualization. Web and operational data flow into BigQuery as source tables and are transformed into curated reporting tables through scheduled pipelines.

These reporting tables feed into Looker Studio, where new calculated fields can be applied and dashboards are built for clear, actionable insights. The setup ensures reliable data, efficient reporting, and a sustainable foundation for future analysis.

Results

With Universal Analytics sunset, Global Fishing Watch’s web tracking was successfully aligned with GA4 best practices. The BI reporting setup transitioned smoothly to GA4 data, with enhancements to the user experience and content while ensuring resource efficiency.

Their team now benefits from:

• Clean, accurate data tailored to their needs
• Custom GA4 dashboards delivered quickly to meet the UA sunset, tailored to different levels of expertise
• An optimized reporting pipeline that reduces cloud costs.

We wanted to acknowledge that the Global Fishing Watch team also played an important role throughout the project, sharing input, context, and technical support that contributed to the successful outcome.

The project concluded with a workshop for the GFW team on how to use and adapt their new setup. Since then, our collaboration has continued, with ongoing support for analytics-related questions and requests.

Working with Global Fishing Watch has been meaningful and rewarding for us personally – not only because of the technical challenge, but because of the impact their mission has on ocean transparency and sustainability.

Need help with dashboards that fit your data and your goals? We help teams create fully customized reporting solutions. Request a free consultation, and one of our experts will get back to you shortly!

The post Case Study: Looker Studio Dashboard Migration and Custom BI Setup with Google Analytics 4 appeared first on scandiweb.

You can find plenty of articles about exporting tracking extract data from Salesforce Marketing Cloud (SFMC) online. I relied on a few of them in the beginning. 

However, the default export option to S3 features the export of one .zip file. That’s not very usable if you need to use those files in further pipelines. You would need to unzip the data. That was a bit puzzling for me at that moment. 

Eventually, I came up with a solution where, upon exporting a .zip file to AWS S3, a Lambda function triggers, unzips the file, and then sorts each file into the right folder by its name. It also adds a date suffix to each file, so you always know when it was exported.

If you’re running into the same issue, I’ve written down all the steps I took – and included the full Lambda code – so hopefully it will save you some time.

After going through additional pipelines, this data was fed into streams in the Salesforce Data Cloud CDP, thus allowing for a better understanding of customer email interactions. 

Also read:

• The Complete Guide to Data Ingestion in Salesforce Data Cloud
• A Practical Guide to Identity Resolution in Salesforce Data Cloud

What are tracking extracts in SFMC?

Tracking extracts are raw, event-level exports from Salesforce Marketing Cloud. Each one is a flat .csv that shows your email opens, link clicks, bounces, unsubscribes, and so on.

You can schedule these exports to land in S3 (or another external store), then pipe them into analytics platforms, data warehouses, or Salesforce Data Cloud.

Here’s a view of how these tracking extract tables connect: 

Why export tracking extracts?

Three reasons:

1. You want more control over the data. SFMC’s reporting tools are limited, while external exports let you clean, filter, and join data your way.
2. You need more extract types. The built-in Starter Bundles only cover a handful of feeds, but tracking extracts open access to everything available, so you can pick and choose what to load into Salesforce Data Cloud.
3. You want to backfill history. Bundles can’t reach past recent activity. Tracking extracts let you go back 30 days per batch.

How the automated export works

Here’s the flow you’ll build:

1. SFMC automation schedules a tracking extract and outputs a .zip file to a designated S3 “input” bucket
2. A Lambda function is triggered when a new .zip arrives
3. The Lambda:

• Unzips the archive
• Renames each CSV with a date suffix
• Sorts files into S3 destination folders by filename

In the end, you have clean, clearly labeled .csv files in your S3 bucket ready for use in pipelines, dashboards, or customer data platform (CDP) ingestion.

Could you customly use SFMC’s SOAP/REST APIs instead? Sure. But unless you need dynamic logic or tight integration, Automation Studio provides a simpler, low-code way to handle this.

Sounds good? Let’s proceed!

Step 1: Set up your export in Salesforce Marketing Cloud

Use Automation Studio to run the export

Automation Studio is SFMC’s low-code workflow engine. It allows you to string together assets like data extracts, imports, SQL queries, scripts, and file transfers and schedule them to run automatically.

For this setup, you’ll need to configure an automation:

• Data Extract to generate the .zip file
• File Transfer to send that file from SFMC’s internal storage (Safehouse) to S3

You’ll also need to set up a connection between SFMC and your AWS S3 bucket before the export can happen.

A note on Safehouse: It’s SFMC’s secure internal staging directory, encrypted at rest and separate from your FTP, where your export files are held before transfer.

Create AWS credentials for SFMC

1. In your AWS console, go to IAM → Users → Create user (set a user name, e.g., sfmc-tracking-extract-connector or anything descriptive)

2. Under Permissions, choose Attach policies directly → then Create policy

Use the JSON editor to define what this user can do. Grant read/write access to the specific S3 bucket and folder where your exports will land.

Here’s the code to use (change your bucket/folder data):

{
  // The policy language version
  "Version": "2012-10-17",

  // A list of individual permission statements
  "Statement": [
    {
      // A unique identifier for this statement; you can name it whatever you like
      "Sid": "AllowMCS3AccessToBucket",

      // Specifies whether to allow or deny the actions in this statement
      "Effect": "Allow",

      // Which S3 actions are permitted
      "Action": [
        "s3:ListBucket"    
      ],
      // Which resources these actions apply to
      "Resource": [
        "arn:aws:s3:::your-bucket-name"    // Your S3 bucket’s ARN
      ]
    },

    {
      // Another identifier for grouping object-level permissions
      "Sid": "AllowMCS3AccessToBucketContent",
      "Effect": "Allow",

      "Action": [
        "s3:PutObject",        
        "s3:GetObjectVersion",  
        "s3:GetObject",          
        "s3:DeleteObject"     
      ],
      "Resource": [
        "arn:aws:s3:::your-bucket-name/zip-files/*",   // All files inside zip-files/ (adjust to your folder)
        "arn:aws:s3:::your-bucket-name/zip-files"      // The folder path itself
      ]
    }

  ]
}

Tip! You can find the bucket ARN if you go to the Bucket → Properties.

3. After creating the policy, review the settings, attach tags if needed, and Create user

4. Generate access keys by clicking Create access key, choose Third party, and acknowledge the warning

Important! Save the Access Key ID and Secret Access Key now – this is the only time you’ll see the secret; store them securely.

Add your S3 bucket to SFMC

1. In Salesforce Marketing Cloud, go to Setup → Administration → Data Management → File Locations. Click Create and choose Amazon S3
2. Fill in the form with the credentials you just generated:

• Access Key ID
• Secret Access Key
• Bucket Name
• (Optional) Prefix or folder path
• AWS Region

Things to double-check:

• Your access key, secret key, or role ARN for typos – invalid credentials will block all exports
• The region must match exactly; otherwise, SFMC won’t find your bucket
• Only enable Transfer Acceleration if you’ve enabled it in your bucket settings
• Make sure your IAM policy includes the required S3 permissions for listing, reading, and writing files.

Step 2: Set up the automation

1. In Automation Studio, click New Automation, name it something like SFMC Tracking → S3, and add these two activities in order:

• Data Extract
• File Transfer

2. Configure Data Extract

• Name: sfmc_te_%%Month%%%%Day%%%%Year%%.zip (Date tokens auto-insert the run date into the filename)
• Type: Tracking Extract
• Range: Rolling 1-day window (to grab the previous day’s data)
• Format: CSV
• Encoding: Choose what fits your system (UTF-8 is standard)
• Options: Select the tracking types you want: opens, clicks, bounces, etc.
• When you’ve double-checked everything, click Finish

3. Configure File Transfer

• Action: Move file from Safehouse
• File Pattern: Use the same name as above (e.g., sfmc_te_%%Month%%%%Day%%%%Year%%.zip)
• Destination: Choose the S3 file location you set up
• Click Finish to save

4. Once both steps are configured, add a Schedule to run the automation daily (or your preferred interval) and click Save. Flip the toggle to activate the schedule if it is paused and inactive; optionally, click Run Once to test and ensure your configurations are valid.

Step 3: Set up the AWS Lambda function to unzip and organize your export

AWS Lambda is a serverless compute service that runs your code in response to events, like a new file landing in S3. 

You could also use AWS Glue (with its visual ETL interface or custom scripts) for batch data jobs, but Lambda excels at real-time, event-driven tasks.

Create a Lambda function

1. In your AWS Console, go to Lambda → Functions → Create Function
2. Select Author from Scratch
3. Set a name (e.g., unzip-sfmc-tracking-exports)
4. Runtime: Python 3.12
5. Create or choose an execution role with permissions to access S3

You can attach these custom policies and then proceed to create a function:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetObject",
                "s3:GetObjectVersion",
                "s3:PutObject"
            ],
            "Resource": [
                "arn:aws:s3:::bucket", //adjust the bucket name
                "arn:aws:s3:::bucket/*" //adjust the bucket name
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        }
    ]
}

Set up the trigger

This part is what makes the Lambda function run automatically.

1. In your Lambda, scroll to the Triggers section → Click Add trigger

2. Choose S3 as the source
3. Specify the input bucket
4. Select the file to react to all the object creation actions
5. Suffix filter: .zip, so that the function reacts only to ZIP files in the location
6. Click Save

Add the Python code

1. Go to the Code tab in your function, where you’ll see a built-in code editor – paste in your unzipping logic here

Here’s what the code does:

• Detects the new zip file
• Unzips the contents into memory
• Renames each file with a run-date suffix
• Sorts the files into folders based on the filename

2. Add the following Python code. The structure of your extracted files depends on which tracking extract types you selected (e.g. _click.csv, _open.csv, etc.). If you use different naming conventions, adjust the logic as needed.

import boto3
import zipfile
import os
import tempfile
import re

s3_client = boto3.client('s3')

# Complete mapping of file names to folders
folder_mapping = {
    "bounces": "tracking-extracts/bounces",
    "click-impression": "tracking-extracts/click-impression",
    "clicks": "tracking-extracts/clicks",
    "complaints": "tracking-extracts/complaints",
    "conversions": "tracking-extracts/conversions",
    "list-membership": "tracking-extracts/list-membership",
    "lists": "tracking-extracts/lists",
    "not-sent": "tracking-extracts/not-sent",
    "opens": "tracking-extracts/opens",
    "send-impression": "tracking-extracts/send-impression",
    "send-job-impression": "tracking-extracts/send-job-impression",
    "send-jobs": "tracking-extracts/send-jobs",
    "sent": "tracking-extracts/sent",
    "status-change": "tracking-extracts/status-change",
    "subscribers": "tracking-extracts/subscribers",
    "surveys": "tracking-extracts/surveys",
    "unsubs": "tracking-extracts/unsubs",
    "multiple-data-extension-send-lists": "tracking-extracts/multiple-data-extension-send-lists"
}

def extract_date_suffix(filename):
    # Pattern for _8digits_8digits or _8digits at the end before .zip
    pattern_range = re.compile(r'_(\d{8})_(\d{8})\.zip$')
    pattern_single = re.compile(r'_(\d{8})\.zip$')
    pattern_any = re.compile(r'_(\d+)\.zip$')
    
    # Check for range pattern first
    match = pattern_range.search(filename)
    if match:
        return f"{match.group(1)}_{match.group(2)}"
    
    # Check for single date pattern
    match = pattern_single.search(filename)
    if match:
        return match.group(1)
    
    # Check for any number of digits pattern
    match = pattern_any.search(filename)
    if match:
        return match.group(1)
    
    return None

def transform_filename(file_name):
    # Add hyphen between lowercase and uppercase letters and convert to lowercase
    transformed = re.sub(r'(?<=[a-z])(?=[A-Z])', '-', os.path.splitext(file_name)[0]).lower()
    return transformed

def lambda_handler(event, context):
    bucket_name = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']
    date_suffix = extract_date_suffix(key)
    
    if not date_suffix:
        print(f"Invalid filename format: {key}")
        return {
            'statusCode': 400,
            'body': 'Invalid filename format'
        }
    
    with tempfile.TemporaryDirectory() as tmpdir:
        download_path = os.path.join(tmpdir, os.path.basename(key))
        
        s3_client.download_file(bucket_name, key, download_path)
        
        with zipfile.ZipFile(download_path, 'r') as zip_ref:
            zip_ref.extractall(tmpdir)

        for file in os.listdir(tmpdir):
            if file != os.path.basename(key):  # Don't upload the original zip file
                file_path = os.path.join(tmpdir, file)
                
                # Transform the filename and check against the folder mapping
                base_name = os.path.splitext(file)[0]
                transformed_file_name = transform_filename(base_name)
                folder = folder_mapping.get(transformed_file_name)
                if not folder:
                    print(f"Skipping file: {file} (no matching folder)")
                    continue
                
                # Rename the file to include the date(s)
                new_file_name = f"{base_name}_{date_suffix}{os.path.splitext(file)[1]}"
                
                # Upload the renamed file to the correct folder
                s3_client.upload_file(file_path, bucket_name, f"{folder}/{new_file_name}")

    return {
        'statusCode': 200,
        'body': 'Files unzipped and uploaded successfully'
    }

3. When you’re done, click Deploy to save and activate the function
4. Check permissions if the function fails to access the bucket (missing GetObject, PutObject, or ListBucket)

Great! Next time your SFMC automation runs:

• A .zip file lands in the input folder in S3
• Lambda triggers automatically
• Files are extracted, renamed, and sorted
• Output files show up in clean, ready-to-use folders

Once the export and unzip process is running smoothly, there’s plenty more you can automate:

• Stream cleaned files into your data warehouse
• Add a second pipeline to load files into your CDP or other destination
• Set up notifications via SNS or Slack when files are ready.

This setup works well if you’re building a modular analytics pipeline, one where each part of the process (export, unzip, validate, ingest) is traceable and easy to debug.

If you’re facing issues with Salesforce Marketing Cloud exports, want to simplify your analytics setup, integrate a CDP, or need a hand building out real-time pipelines like this, scandiweb can help. Reach out to us today, and we’ll get back to you in 48h!

The post How to Automate SFMC Tracking Extracts with Unzipping in AWS [Code Included] appeared first on scandiweb.

A luxury fashion house in New York partnered with scandiweb to rebuild its customer data infrastructure and improve how it personalized experiences across channels. With boutiques, outlet locations, international stores, and a high-touch clienteling model, the brand needed a system that could unify fragmented data, support calculated traits, and power smarter segmentation. 

Across the 5 years of using a customer data platform (CDP), they’ve doubled revenue, automated hundreds of hours of reporting work, and now drive over 40% of online revenue through targeted email and SMS, reducing reliance on paid media, strengthening loyalty from high-value customers, and saving money while gaining complete control over their in-store and digital customer data.

About

Our client is a New York City-based fashion house that specializes in women’s apparel, footwear, and accessories, offering a range of modern and sophisticated designs. They sell in physical boutiques and online with an eCommerce store powered by Magento. In the boutiques, stylists and store clerks enhance the shopping experience by offering personalized recommendations based on customer preferences.

Their operations rely heavily on a CDP to support personalization and data-driven decision-making across channels.

Also read:
Webinar Recap: How to Increase Your eCommerce Revenue 2-3x with CDPs

Challenges

The brand’s data ecosystem was highly complex. With operations spanning flagship boutiques, outlet and international stores, stylists providing 1:1 guidance, and an eCommerce store powered by Magento, customer interactions were scattered across many systems. Each customer could be represented by multiple identifiers – email, phone number, loyalty account, purchase history, and in-store interactions, making it difficult to form a unified profile.

At the start of our collaboration, the client was already using an advanced customer data platform to support its personalization and marketing efforts. Over time, however, specific challenges, such as limited flexibility in managing identity resolution rules and increasing demands on reporting, led them to explore new solutions. With a focus on scalability, internal control, and deeper integration across its systems, we chose to migrate to Salesforce Data Cloud.

• Moving to a new platform without disrupting existing workflows
  A major concern during the migration was ensuring that existing workflows remained uninterrupted. The brand faced a strict deadline before their Acquia contract expired, which would have required committing to another year of service. Within this tight timeframe, we had to complete the migration to Salesforce Data Cloud, ensure all systems were integrated, and thoroughly test that data processes continued running smoothly without disruptions.
• Reporting inefficiencies and missed revenue opportunities
  The fashion brand needed deeper insights into customer purchasing behavior, but limited reporting tools required extensive manual effort to compile and analyze data. Since reports could not be generated automatically, teams had to manually export raw data, transfer files via SFTP (Secure File Transfer Protocol), and piece together information using pivot tables and VLOOKUP functions. This time-consuming work diverted resources away from tasks with higher ROI, like more time spent identifying upselling and cross-selling opportunities.
• Identity resolution limitations
  While the team had visibility into why customer profiles merged or didn’t merge, they could not modify the matching logic without support from Acquia. It was difficult to react quickly to data discrepancies or evolve identity resolution rules as business needs changed. 
• Limitations in digital marketing insights and customer acquisition tracking
  Acquia lacked the ability to link website visits, product interactions, and purchase intent to individual customer profiles, leaving marketing teams without clear visibility into customer journeys. Additionally, the platform did not support direct integration with advertising networks, meaning customer data could not be synced with Google Ads or Meta. Without this connection, the company could not run targeted ad campaigns or measure how ads influenced purchases. The transition to Salesforce needed to bridge this gap by integrating web event tracking and aligning customer interactions with marketing performance.
• Scalability concerns and long-term growth
  The company needed a system that could evolve with their customer data strategies without incurring high implementation costs. Already using Salesforce Marketing Cloud, they benefited from good data exchange within the Salesforce ecosystem, making Salesforce Data Cloud a future-proof choice for expanding capabilities and maintaining operational efficiency over time. 

Approach

scandiweb implemented a flexible, scalable solution to migrate to Salesforce Data Cloud, enabling improved customer segmentation and reduced reliance on external services.

Transitioning from Acquia to Salesforce Data Cloud

The previous system was deeply integrated into the brand’s data workflows, making it critical to preserve existing functionality during the migration. scandiweb implemented Salesforce Data Cloud to give the internal team greater control over data processes and simplify future changes.

A key part of the migration involved integrating Salesforce Data Cloud with their existing technology stack, including Magento, in-store customer relationship tools, and external data sources. 

Data validation and integrity checks were utilized throughout the migration to prevent discrepancies and ensure a clean dataset. We developed customized automation rules, which helped map Acquia’s existing data structures into Salesforce without data loss or corruption. 

The transition process included initial user training to help internal teams get up to speed with the new system. With the most technical onboarding still underway, the brand is building toward full in-house autonomy. The migration to Salesforce Data Cloud laid the groundwork for a scalable and future-ready customer data infrastructure.

New data infrastructure with AWS

As the project progressed, we encountered limitations in data ingestion and transformation capabilities within the initial setup. To address it, we explored external cloud solutions and expanded the existing AWS environment to support more flexible and scalable data operations.

The following AWS services were integrated into the new setup:

• AWS S3
  • Used to store most ingested input data sources
  • Also serves as the storage for processed files ready for ingestion into the Salesforce Data Cloud
• AWS Glue
  • Handles data transformations such as blacklisting, standardization, and API-based tasks
  • Combined visual ETL configuration for simpler workflows with custom code via the Script Editor for more complex processes
• AWS Glue DataBrew
  • Enables visual data profiling and initial data exploration to identify key issues and edge cases
  • Also used to validate outputs during pipeline quality assurance
• AWS Lambda
  • Used for real-time processing jobs triggered by specific events
• AWS Redshift Serverless
  • Implemented as a data warehouse to support structured data access and analysis without infrastructure management overhead.

Identity resolution system update

Identity resolution is the process of matching and unifying customer data across multiple touchpoints to create a single, accurate customer profile. Each individual is recognized consistently across online, in-store, and marketing interactions. Without a proper identity resolution system, businesses face issues like duplicate records and a fragmented view of their audience.

To support unified customer profiles, scandiweb configured Salesforce Data Cloud’s identity resolution framework to fit the existing data logic and structure. Our setup included tools for testing and validating match rules in a controlled environment, ensuring confidence in profile merges before any changes were applied. The migration process also included knowledge transfer and onboarding for internal teams to take ownership of the identity resolution logic moving forward.

Calculated traits and segmentation

With unified customer profiles in Salesforce Data Cloud, the team gained the ability to work with calculated traits – derived attributes that go beyond standard fields from source systems. They gave a more detailed view of customer behavior and preferences.

Examples of calculated traits

• Order metrics: lifetime order count, time since first and most recent purchase, purchase frequency by period (last 12 months, 13–24 months, 24+ months)
• Revenue patterns: lifetime revenue, decile rankings, trend segments
• Engagement: email and SMS sends, clicks, opens, CTR by timeframe
• Web activity: total sessions, last session date
• Preferences: sizes, colours, product types, styles, channels, preferred stylist or store.

Segmentation strategies based on enriched customer profiles

• Full-price vs off-price buyers
• Lifecycle stages (new, inactive, lapsed, reactivated, unidentified)
• Revenue trend groups
• Location-based segments for in-store events
• Product-based segments for tailored communications.

Automated analytics with Tableau

With the implementation of Tableau as the primary business intelligence tool, we created an automated analytics framework. Tableau’s integration with Salesforce Data Cloud enabled the company to automate reporting processes and centralize performance tracking across teams.

Enriching customer segmentation with external data

Customer segmentation plays a key role in our client’s personalization efforts. The previous platform made integrating new data sources difficult, limiting the segmentation depth. With the new system, adding third-party data became significantly easier, enabling more refined and flexible audience segmentation.

With Salesforce Data Cloud, we ensured they gained the ability to ingest and unify external data sources to support more advanced customer segmentation. For example, Census Data enriched segmentation efforts by adding socioeconomic indicators.

Results

1. 85% of revenue generated by re-engaging existing customers

With better visibility into customer history and preferences, the brand focused more on retention and lifecycle-based engagement. Personalized campaigns, proactive churn prevention, and curated in-store experiences helped make the most of their existing customer base.

2. Highly personalized in-store customer experience

The brand had existing customer profile visibility in their clienteling tool, which stylists use to enhance the in-store experience. scandiweb supported migrating this data to Salesforce Data Cloud and preserved the export process to Proximity. We built a new dashboard in Tableau, offering greater flexibility to access and customize customer insights. Unlike frontend changes in the previous clienteling tool, Tableau dashboards could be quickly updated internally to expand available data to stylists without relying on external development.

scandiweb’s implementation of Salesforce Data Cloud enabled them to deliver an even more personalized in-store experience. Staff can access detailed profiles before appointments, including transaction history and preferred product categories, to tailor recommendations more precisely, create a curated shopping experience, and anticipate customer needs.

3. Effective email and SMS marketing communication

Email and personalized SMS marketing contribute over 40% of online sales. By contrast, brands without a CDP often generate just 1–3% of revenue from these channels.

The brand leveraged our consolidated customer data to implement more precise email and SMS marketing segmentation. To engage customers, personalized offers and targeted messaging were sent based on purchase history, browsing behavior, and engagement patterns, delivering promotions aligned with their shopping habits and preferences. 

4. Enhanced identity resolution

Salesforce Data Cloud allows them to test, compare, and deploy identity resolution rules. Instead of relying on predefined, unchangeable rules, they can now adjust identity resolution settings based on their specific needs, giving them greater control in managing customer data. 

5. Targeted advertising spend and ROAS improvements

With customer data more accessible and organized in Salesforce Data Cloud, we improved how audience segments were activated within Google Ads and Meta Ads. Building on its existing personalization efforts, they can deliver more personalized ads to existing customers and high-intent prospects, potentially reducing wasted ad spend and increasing ROAS. Additionally, third-party data enrichment enhanced customer lifetime value modeling, helping the team better prioritize high-value audiences.

6. Advanced business reporting and BI solutions

Our integration of Salesforce Data Cloud and Tableau enabled a centralized and automated business intelligence system. Teams can now track KPIs automatically, measure the effectiveness of customer segments, and analyze user journeys.

Interactive dashboards allow deeper customer data exploration, with Tableau’s drill-down capabilities for reviewing behavior by segment, transaction history, or web engagement. This has reduced reporting time and improved the speed and accuracy of business decision-making. With access to more reliable data, our client can plan long-term strategies based on customer behavior.

Looking to transform your customer data management? scandiweb can help you leverage Salesforce Data Cloud or any suitable platform to streamline reporting, optimize marketing, and enhance customer engagement. Get in touch today to learn how we can help!

The post Luxury Retail Meets Data-Driven Personalization: Salesforce Data Cloud Success Story appeared first on scandiweb.

Every click, product view, purchase, or support request reveals something about your customer. That is, if you know where to look. In eCommerce, customer data platforms (CDPs) are the power tools for understanding customer behavior and personalizing marketing, meanwhile improving overall customer experience.

Research shows that companies using CDPs achieve 2.9x greater YoY revenue growth compared to those that don’t. However, to achieve those results, you need to fully understand the topic. In our latest webinar, we broke down what a CDP is, what it does, how it works, and what it takes to implement one. Here’s what you need to know.

Watch the full webinar recording above, or read more for all the essentials on how CDPs can help eCommerce retailers grow their revenue.

What are CDPs and why should you care?

A customer data platform (CDP) is software that unifies customer data from various channels, such as eCommerce, mobile apps, POS, live chat, SEO, PPC, and more, into a single, centralized customer profile.

Unlike customer relationship management (CRM), data management platforms (DMP), or data warehouses, a CDP brings together customer data from all sources into one clear profile, online and offline, that stays updated over time. This makes it easier to personalize in real time and connect across channels.

It offers stronger identity resolution than CRMs (which focus on known contacts) and DMPs (which rely on anonymous data), and unlike data warehouses, CDPs are built for analysis and action.

Essentially, CDPs are built specifically for identity resolution and real-time personalization, which most CRMs and DMPs are not.

CDP core values

CDPs bring structure to messy customer data and turn it into something you can use. Here’s what they do best:

• Connect and combine data from all platforms (eCom, CRM, POS, ads, etc.)
• Merge customer info into one clear profile
• Build smart audience segments, including AI-driven ones
• Send personalized messages through email, ads, and more
• Track customer behavior, predict churn, and show segment performance.

Why CDPs are so valuable for customer retention and personalization

Businesses that use CDP show up to 90% reduction in time spent on segmentation, customer journeys, and reporting tasks. 

CDPs also unify data across channels so teams can personalize in real time and act on insights without manual effort. They increase customer loyalty and lifetime value, reduce churn, support data privacy compliance, as well as save time through effective data management, all of which contribute to higher revenue and marketing performance.

Also read:
What is CDP? Guide to Customer Data Platforms for eCommerce

CDPs and AI

AI goes beyond being a trendy term in the context of CDPs; it serves as a practical engine driving better decision-making and more precise targeting. Predictive features, such as anticipating user churn and tailoring messages to be more timely, are some of the ways AI helps CDPs make better use of data.

Here’s how the top platforms today use AI for customer insights, making them more precise and actionable.

Predictive audiences and analytics

Various AI models can help businesses forecast the following customer behavior:

• Who is likely to make a purchase soon
• Who is at risk of churning
• Which customers are likely to respond to a campaign
• How much a customer might spend over their lifetime
• When a customer is most likely to buy again.

Some CDPs with these features are Segment (Twilio Segment), Salesforce Data Cloud (Einstein AI), Bloomreach, and Treasure Data.

Real-time customer data unification and identity resolution

Real-time data unification means bringing scattered customer data into one clear profile automatically and instantly.

AI connects the dots between different devices, email addresses, purchase histories, and more to recognize the same person across platforms. This gives you a complete, up-to-date view of each customer without manual cleanup.

Some of the platforms that have these features are BlueConic and Salesforce Data Cloud.

Automated personalization

Automated personalization uses AI to adapt every interaction to each customer without manual setup. It adjusts everything from messages and website content to product recommendations based on what users engage with the most. 

Platforms like Salesforce Data Cloud, Bloomreach, and BlueConic use this to make personalization faster and more relevant.

Data cleansing and enrichment

Data cleansing and enrichment keep your customer data accurate and complete, so that it’s ready to use. In this case, AI takes care of routine cleanup by removing duplicates and fixing inconsistent and missing fields, so your team doesn’t have to. 

Tools like Treasure Data and BlueConic’s AI Workbench help maintain high data quality without manual effort.

Dynamic segmentation

Dynamic segmentation uses AI to automatically group customers based on how they behave and what they’re likely to do next. It updates segments in real time, so you’re always targeting the right people with the right message. 

Bloomreach, Segment, and Treasure Data make this possible with no constant manual updates.

Customer journey optimization

Customer journey optimization uses AI to track how people move across channels and fine-tune their experience as it happens. It spots drop-off points, adjusts timing, and delivers the right message at the right step, whether that’s on your site, in an email, or in-store. 

Bloomreach, BlueConic, and Salesforce Data Cloud are some of the tools that can handle this in real-time.

Case study: how a New York retailer increased revenue with CDP

A luxury New York fashion retailer struggled with fragmented customer data across online, offline, and loyalty channels, making personalization difficult. Without a unified view, insights like preferences and purchase history had to be manually calculated, limiting effective segmentation and targeted campaigns.

After implementing a CDP, these were the outcomes: 

• 2x revenue growth in 5 years
• 85% of revenue from re-engaged customers
• Over 40% of online sales driven by email and SMS
• Personalized customer service and in-store experience, knowing customer preferences
• Automated business reporting and insights, saving hundreds of hours of manual time
• In-depth customer knowledge, driving smarter product and marketing strategies across teams.

What it takes to implement a CDP platform

Implementing a CDP requires the right team and a solid tech stack. When you’re thinking about the team setup, these are the people to consider:

• Marketing, CRM, and eCommerce managers who define use cases and activation goals
• People who know the customer and the data
• Tech specialists: a CDP specialist, a data (analytics) engineer, and a BI specialist.

For a tech stack, you’ll need:

• A data warehouse to store and organize clean customer data
• A traditional or composable CDP 
• Data transformation tools to clean and transform data if not handled inside the CDP
• BI tools (e.g., Tableau, Power BI, or Looker) for visualization and reporting.

Our scandiweb team has the expertise to manage every aspect of CDP implementation, from defining use cases and activation goals to handling the entire tech stack. Our team of specialists will ensure your data is organized and ready for action, giving you the best results.

How to choose the right CDP platform

Before choosing the right platform, you have to keep in mind that there is no “one size fits all” solution. Here’s what you need to consider when choosing the right tool for your business.

Types of CDPs

The two main categories, traditional and composable, offer different levels of flexibility, control, and ease of use.

Traditional CDPs are packaged, all-in-one platforms that come with built-in tools for data unification, identity resolution, and activation. They’re quicker to set up and easier to manage, making them a good fit for teams that want a ready-to-use solution without heavy internal resources. However, they offer less flexibility when it comes to customization.

Whereas composable CDPs are modular and built on top of your existing data warehouse. Instead of an all-in-one tool, you combine best-in-class tools for each function. This gives you full control and avoids vendor lock-in, but it requires a strong internal data team to manage setup and ongoing operations.

Factors to consider when choosing the right CDP for you

When you’re about to choose a CDP, there are many variables to consider, which is why we here at scandiweb work closely with the client and run an in-depth discovery to evaluate everything properly. These are the key factors to consider:

• Business goals you want to achieve (data unification, personalized marketing, retargeting in ads, or better customer insights)
• Pricing models based on tracked users, event volume, or data records
• Privacy compliance requirements like GDPR or CCPA
• Data source compatibility, as some CDPs offer native integrations, while others require external connectors or workarounds
• Data transformation needs, as some CDPs expect cleaned, structured data before ingestion
• Activation targets like email platforms or ad tools
• Identity resolution flexibility 
• Documentation quality and access to onboarding resources.

Some of the top CDP platforms

1. Salesforce Data Cloud offers strong integration with Salesforce tools and flexible data modeling, but has complex pricing, limited documentation, and non-persistent unified IDs.
2. Bloomreach is user-friendly, cost-effective for small and medium-sized businesses, with solid support and documentation, though it has a learning curve and less intuitive data validation.
3. Segment excels in integrations and data governance, with native messaging and AI features, but lacks built-in reporting and can become costly with scale.
4. Insider CDP includes built-in automation and a strong UI, but it offers fewer integrations and has pricing and stability issues.
5. Adobe Experience Cloud is powerful but best suited for companies already using the full Adobe stack.
6. Pimcore is open-source and flexible, ideal for custom setups, but has fewer ready-made connectors.
7. RudderStack is warehouse-native, giving full data ownership and flexibility, but requires technical expertise for setup and maintenance.

Summary: why a CDP is a must for any eCommerce store

Retailers often struggle with disconnected systems and scattered customer data. This limits the ability to satisfy customers and slows down personalization efforts and business decisions. Bringing online and offline customer data together solves a key challenge for businesses. CDPs provide the central system needed for this.

Take, for example, the New York luxury fashion retailer. With the help of our CDP experts and all the right tools, we were able to increase their revenue more than twice. In-depth customer knowledge is one of the driving factors for creating smarter product and marketing strategies.

With the rising role of AI in marketing, CDPs are becoming even more effective for delivering true data-driven insights and actions. Therefore, retailers that don’t use CDPs in their eCommerce are losing to their competitors. 

Want a clearer view of your customers? Get in touch with us and see how unified customer data leads to more effective marketing and stronger customer loyalty, producing better business results.

The post Webinar Recap: How to Increase Your eCommerce Revenue 2-3x with CDPs appeared first on scandiweb.