SFCC Field Notes - Oleksandr Katerynchuk

Bot Management Automation for SFCC eCDN with Logpush

2026-10-08T00:00:00Z

In the Logpush article I said you can act on your eCDN logs, not just store them. Acting can mean a lot of things: a dashboard that shows who your traffic really is, a look back at what happened during last month's sale, or a firewall rule. This article is about that last one, and about automating it.

The short version: Cloudflare already gives every request a bot score, and Logpush ships that score to your bucket. You just can't use it in a firewall rule. So I built a small proof of concept that reads the score from the logs, finds the IPs that keep scoring like bots, and writes eCDN firewall rules for them. A second loop removes those rules once they stop matching.

Here is the demo:

The score is in the logs, not in the rules

Every HTTP request record in Logpush carries a BotScore from 1 to 99. Close to 1 is almost certainly a bot, close to 99 is almost certainly a human. In the demo there's a request for a pizza page on my sandbox (no idea why) that scored 2, with BotScoreSrc set to Machine Learning.

The obvious next step would be a rule like "challenge anything with a score below 30". The Cloudflare field for that is cf.bot_management.score, and if you type it into the Business Manager expression editor, you get an error. Enforcing on bot score is part of Cloudflare Bot Management, a paid product with its own entitlement. On the eCDN the score is informational: you can read it, but you can't act on it at the edge.

What eCDN rules do understand is IPs, ASNs, countries, paths and user agents. So the workaround is to move the decision out of the edge. Read the score after the fact and translate it into something a rule can match, like an IP address.

What about the new Known Bot field?

Release 26.9 added two fields to eCDN custom firewall and rate limiting rules. cf.client.bot is true for any verified bot, and cf.verified_bot_category narrows it down to a category like Search Engine Crawler, AI Crawler, AI Search, Feed Fetcher or Aggregator. Business Manager calls it Known Bot, and both fields work in the CDN Zones API too.

Known Bot in the rule editor. One click, no ASN lists.

These are useful. Until now, the usual trick to keep Googlebot and Bingbot out of a rate limit was to exclude Google's and Microsoft's ASNs by number. Now you can exempt verified bots directly, or treat AI crawlers differently from search engines if your business wants that.

But verified bots are the polite ones. They announce themselves, and Cloudflare checks they are who they claim to be. The traffic that hurts (scrapers, credential stuffers, inventory hoarders) announces nothing. The release note says it plainly: other Bot Management fields, including bot score, still require the separate entitlement. Known Bot is how you let the good bots through. It doesn't catch the bad ones.

The idea in one picture

Strip away the SFCC details and the concept looks like this:

flowchart LR
    V[Visitors] --> EDGE[CDN edge
firewall rules]
    EDGE --> O[Origin]
    EDGE -. request logs .-> ST[(Log storage)]
    EDGE -. firewall event logs .-> ST
    ST --> D[Detect
low score + high volume]
    ST --> C[Clean up
rules gone quiet]
    B[Business thresholds
+ human review] -.-> D
    D -->|create or update rules| API[CDN API]
    C -->|remove rules| API
    API --> EDGE

The edge logs every request. One function reads the request logs, finds IPs that are both busy and bot-like, and asks the CDN API to put them in a rule. Another function reads the firewall event logs and removes entries nobody has hit for a while. The business sets the thresholds, and a person decides when a rule goes from watching to blocking.

Nothing here is specific to Commerce Cloud. Any CDN that gives you request logs with a bot score and an API for rules can work this way.

What the POC does

For the demo I built it as an SFCC cartridge with a custom job, because that was the fastest way to show the whole loop in one place. The job reads the files the HTTP requests Logpush job drops into S3, and every setting is a job parameter:

The default detection settings. Every threshold is a job parameter, so tuning doesn't need a deploy.

Bot score threshold. Requests below this count as bot-like. The default is 30. In the video I raised it to 70 on purpose so that my small sandbox traffic would trigger something. That's far too aggressive for real traffic.
Minimum requests and window. An IP only becomes a candidate with at least this many low-score requests inside the window. The default is 20 in 15 minutes (the video used 10).
Action. Log, managed challenge, JS challenge or block. I only ever used Log.
TTL days. How long an IP can stay in a rule without a single firewall hit before cleanup drops it. 14 days by default.
Max rules. A cap on how many rules the automation may own. A zone allows 500 custom rules in total and you have your own rules too, so leave room.

There's also a dry run switch that logs every decision without touching the zone, and an allowlist of IPs that must never be blocked.

The numbers depend on your Logpush filter

"20 requests in 15 minutes" means very different things depending on what your Logpush job ships. In the Logpush article I suggested keeping only text/html responses. With that filter, one log line is roughly one page view or AJAX call, and 20 low-score lines is a real pattern.

If the job ships everything, a single page view brings its CSS, JS, images, fonts and icons along, easily dozens of lines. Now 20 requests is less than one page load, and one shopper who happens to score low on one visit becomes a candidate. The counts also swing with page weight, so a heavy product page counts more than a light one.

So decide the filter first, then pick the thresholds, and revisit them every time the filter changes.

On each run the job groups the window's requests by IP, keeps the IPs that cross both thresholds, and packs them into rules named AUTOBLOCK-001, AUTOBLOCK-002 and so on. A rule expression can be up to 4096 characters, so one rule holds a couple of hundred IPs before the next one starts. The job only touches rules with its own prefix. Your hand-made rules are read for the report and never changed.

It's also declarative. Every run works out the full list of IPs that should be in rules and makes the zone match it, so if a run dies halfway, the next one fixes it.

Here is the run from the video:

686 log files, 99 records inside the window, 7 unique IPs. One new candidate, plus one still remembered from an earlier run.

Each IP gets logged with its evidence: how many low-score requests, the lowest score, the ASN and the country. Later, when someone asks "why is this IP blocked?", you have an answer. In this run one IP had 82 low-score requests with a minimum score of 3, and the other had 116 with a score of 2.

And here's the result in Business Manager, a new rule at the bottom of the list with the Log action:

AUTOBLOCK-001 lands after the hand-made rules, set to Log.

Why IPs and not ASNs

Blocking by ASN catches more with fewer rules, and it's much riskier. One ASN can be a whole mobile carrier, a cloud provider or a corporate network, with real shoppers mixed in with the bots. An IP has a much smaller blast radius. It's still not zero, because many people can share one IP behind a corporate network, a mobile carrier or a VPN.

One more thing from the Logpush article: if another CDN sits in front of the eCDN, ClientIP is that CDN's edge IP, not the shopper's. Automated IP blocking in that setup would block your own front CDN. In a stacked setup, do this at the outermost layer instead.

Custom rules or rate limiting rules?

The eCDN has two kinds of rules that can match an IP, and the POC uses custom rules. They fit what the automation produces: a verdict. By the time an IP reaches a rule, the logs have already shown it's bot-like, so the rule only has to match it and apply an action. Custom rules give you room for that (500 per zone), every action including Log, and an order you control.

Rate limiting rules do a different job. They count requests per IP at the edge, in real time, and act when the count goes over a limit within a period. They need no logs, but they can't see the bot score either, and a zone gets only 50 of them. So they complement the automation rather than replace it: keep a general rate limit for everyone (with Known Bot exempted), and let the automation catch the IPs that stay under it but still score like bots.

There is a middle ground: instead of blocking flagged IPs, put them in a rate limiting rule with a stricter limit. A real person who scored low by bad luck never browses fast enough to hit it, but a scraper does. It's a softer landing for false positives, and it costs you one of the 50 slots.

Why a job on SFCC is not the real-world shape

The POC works, but watch the run in the video and you'll see where the time goes: downloading .gz files from S3 into Commerce Cloud, unpacking them and parsing them. Most of the job is spent moving logs to where the code is. That doesn't scale with real traffic.

In a real setup you flip it around and process the logs where they land. That could be an AWS Lambda function that runs whenever a new file shows up in the bucket, or a scheduled Athena query over the same files. The only thing that needs to reach Commerce Cloud is the result: a few calls to the CDN Zones API to create, update or delete rules. Your storefront instance stays out of it.

The CDN Zones docs have SCAPI request examples for every call you need: create, list, update, reorder and delete for custom rules, and the same set for rate limiting rules. One gotcha from building the POC: the API client's token needs two scopes, the tenant scope SALESFORCE_COMMERCE_API:<tenant_id> and sfcc.cdn-zones.rw. Leave out the tenant scope and the token is still issued just fine, but every call comes back 403.

Two loops: one creates, one cleans up

You only get two Logpush jobs per zone, and I suggested spending them on HTTP requests and firewall events. That split fits this setup exactly, one dataset per loop:

The create loop reads HTTP request logs, finds new bot-like IPs and adds them to rules.
The cleanup loop reads firewall event logs. Every time an automated rule matches a request, a firewall event lands in the bucket with the client IP. If an IP hasn't triggered anything for N days, cleanup takes it out of the rule, and an empty rule gets deleted.

Why bother with cleanup? Bots rotate IPs, so most entries go stale within days. Without cleanup you slowly fill the 500-rule limit with addresses nobody uses anymore. And IPs get reassigned: the address a scraper used last month might belong to a real shopper today.

My POC does both in one job to keep the demo short. In real life I'd split them into two jobs or functions, each with one purpose, its own schedule and its own failures.

Put together, every IP goes through the same lifecycle:

stateDiagram-v2
    [*] --> Log: detected
    Log --> Challenge: reviewed, no false positives
    Challenge --> Block: reviewed again
    Log --> Removed: quiet for N days
    Challenge --> Removed: quiet for N days
    Block --> Removed: quiet for N days
    Removed --> [*]

Start with Log. Always.

Every automated rule should start life with the Log action. A Log rule matches and records, but lets the request through. You get firewall events showing exactly who the rule would have caught, and nobody is actually blocked.

Leave it in Log long enough to see a normal week, and ideally a busy day like a sale or a launch. Then look at who matched. Real browsers on home connections? Your own monitoring? A payment provider's callbacks? Every one of those is a shopper or partner you would have blocked.

When you move on, go to managed challenge before block. A challenge lets a real person through after a quick check, and a bot usually fails it. Block is the last step, for when you're sure.

A few guardrails I'd have in place before the first run:

Dry run, then Log, then challenge. Never straight to block.
An allowlist for your monitoring and uptime checks, load tests, payment and fraud providers, integration partners and office IPs.
Allow rules on top. Custom rules are evaluated in order, and new rules land at the bottom. Keep your allow rules (with a skip action) above the automated ones.
A kill switch. Someone on call should be able to turn off every automated rule in seconds, and stop the job that would recreate them.
A cap on how many rules and IPs the automation can own.
An audit trail that says, for every IP, why it was added and when.

The business owns the cutoff

This part isn't technical. Salesforce is clear about who does what. From the Bot Management guide:

Bot protection efforts by B2C Commerce are focused primarily on maintaining the availability, stability, and performance of our multi-tenant commerce platform. [...] customers own the monitoring and tuning of the controls to protect against bots on a continuous basis.

So the controls are yours, and the thresholds are a business decision disguised as a number. A score of 30 or 50, 10 requests or 100, challenge or block: each choice trades blocked bots against blocked shoppers. Engineering can build the loop and show the data. The business has to decide how much risk is acceptable and sign off on it. And someone has to keep watching for as long as the automation runs. This isn't a set-and-forget job.

Before you build this

This POC is a cheap way to use a signal you already have. It's not the only option, and often not the first one I'd reach for:

Rate limiting rules (up to 50 per zone) catch a lot of noisy bots by request rate alone, no logs or code needed. Exempt verified crawlers with Known Bot and they cover a lot of ground.
The managed WAF rulesets are already in your zone. Check their actions before you write your own rules.
A dedicated bot product. Behavioral detection that no log job will match. More on that next.

Third-party bot protection

If bots are a serious business problem for you, a dedicated product is the way to go. This slide from a bot management deck sums up the two shapes they come in:

Two places to stop bots: in the storefront with a cartridge, or in front of the eCDN with your own CDN.

Cartridge integrations, at the origin. HUMAN, Netacea, DataDome, Radware Bot Manager and F5 Bot Defense have integrations that run as part of your storefront. Sitting in the app tier, they see all the traffic that reaches your site, whatever route it took. The catch is in the name: a bot is only stopped once it's already at your origin, so every blocked request still costs you origin resources.

A stacked CDN, at the edge. Akamai Bot Manager or Cloudflare Bot Management, running in your own CDN account in front of the eCDN. Bots are stopped before they reach Commerce Cloud at all, and that's the only one of these options where you can enforce on a bot score at the edge. The price is setup and care. The eCDN now only sees your front CDN, so its own protection (WAF, firewall and rate limiting rules, geo blocking) is effectively bypassed, and ClientIP in Logpush is your CDN's edge, not the shopper. Plan to follow the stacked CDN best practices closely.

Either way, these are partner products, not Salesforce features, so integration support and pricing come from the vendor. They also cost real money. DataDome is one of the few that publish prices: when I recorded the video, their plans started at about $3,800 a month, and the Enterprise tier at over $13,000. To see who offers a Commerce Cloud integration, search AppExchange for bot apps.

Wrapping up

The eCDN already scores every request. It just won't let you act on the score. Logpush gets the score out, a detection loop turns repeat low-score IPs into Log rules, and a cleanup loop takes them back out once they go quiet. Process the logs where they land and send only rule changes to the CDN API. And keep a person in charge: the business sets the cutoffs, every rule starts in Log, and nothing gets blocked until someone has looked.

Happy bot hunting. 🤖

Shopper Profile Sync for SFCC and Salesforce

2026-10-06T00:00:00Z

If you ever had to get B2C Commerce customers into Salesforce Core, you know it used to be a project of its own. Most of the time that project was b2c-crm-sync, an open-source enablement framework. It was designed to teach the B2C customer data strategy, it is maintained by the community, and its README is very clear about what that means:

Please remember that this project should not be treated as Salesforce Product. [...] Customers and partners implement this at-will with no expectation of roadmap, technical support, defect resolution, production-style SLAs.

So you owned all of it: a Node CLI, SFDX deployments, OCAPI and WebDAV permissions, JWT certificates, an Account Manager client, plus the Apex, Flows and Platform Events on the Core side. And it hasn't seen an update in about three years.

Now there is a native way. Shopper Profile Sync went GA in June 2026. You connect your B2C Commerce instance to a Salesforce org from Business Manager, set up a few rules in Core, flip a switch, and registered shoppers start showing up as Person Accounts. Edit one of those Person Accounts in Core, and the change lands back in Commerce about a minute later.

The Salesforce Connection you create along the way is also what Merchant Agent and Shopper Agent build on.

I recorded the whole setup on a sandbox, from connecting the two clouds to watching a profile travel both ways.

Shopper Profile Sync or Unified Profile Sync?

Same feature, two names. The documentation, the release notes and the card in Business Manager all say Shopper Profile Sync. The feature switch says Enable Unified Profile Sync Feature, and the system job and the Business Manager API use "unified profile" too. I'll stick with Shopper Profile Sync here, but if you are searching for answers, try both.

How it works: two directions, two mechanisms

"Two-way sync" sounds symmetric. It isn't, and that is the most useful thing to understand before you start.

flowchart LR
    S[Shopper registers
or edits profile] --> B2C[(B2C Commerce
customer)]
    B2C -->|"scheduled job
every 30 min, 10 min on ODS"| PA[(Salesforce
Person Account)]
    PA -->|"event, about 1 min"| B2C
    A[Service agent
edits record] --> PA

Commerce to Salesforce is a scheduled job. A system job picks up new and changed profiles and pushes them to Salesforce. It runs every 30 minutes in production and every 10 minutes on on-demand sandboxes, up to 100,000 records per run. That cadence arrived in 26.9. Before that it was hourly, so if you read older threads complaining about the wait, that's why.

You don't have to guess when the next run is. The Shopper Profile Sync card under Administration → Global Preferences → Salesforce Connection shows the last sync status and the next scheduled sync:

The card tells you exactly how long you'll be staring at the Accounts list.

Salesforce to Commerce is event-driven. When someone edits a synced Person Account in Core, the change is pushed to Commerce right away. The docs say about a minute. In the video I renamed a shopper in Core, refreshed the storefront, and the new name was already there.

The fine print behind "two-way"

Person Accounts are only created from the Commerce side. If you create a Person Account by hand in Core, no B2C customer appears.
Updates go both ways, but only for linked records. That means shoppers who went through the sync from Commerce first, or who got matched to an existing Person Account by your duplicate rules (more on that below).
Only registered shoppers sync. Guest checkouts don't create Person Accounts through this feature.
Deletes don't sync. Deleting a customer in Commerce leaves the Person Account in place. Deleting a linked Person Account in Core doesn't delete the customer either. The link is dropped, and the next sync creates the Person Account again. If you are cleaning test data out of a sandbox org, turn off Auto-Sync first, or the records come back.

There is one more nuance for new registrations. Since 26.8, a fresh registration can create the Person Account in near real time instead of waiting for the next job run, on headless storefronts (PWA Kit, Storefront Next). My sandbox runs SFRA, and the new account waited for the job, which is what you see in the video.

Before you start

A B2C Commerce sandbox on a recent release. The feature moved fast between 26.6 and 26.9, so the newer the better.
A Salesforce org to pair with. For testing, use a Salesforce sandbox or a demo org, not production. The connection is one to one and Person Accounts can't be switched off, so experiments belong somewhere you can throw away. For the real setup, the org needs Enterprise or Unlimited edition with Data 360 provisioned.
The Salesforce Connection page in Business Manager. If Administration → Global Preferences → Salesforce Connection isn't there, check Feature Switches for Unified Commerce Configuration. If the page is there but the Shopper Profile Sync card isn't, enable Enable Unified Profile Sync Feature.
A look at your Change Data Capture usage. Core reports synced records back to Commerce through Account and Contact change events. If your org already has Change Data Capture on for Contact, setup shows a warning: a large first sync can produce a lot of change events and eat into your daily event allocation. It doesn't block anything, but check your limits before you sync a few million shoppers.
Pick your pairing. One B2C Commerce instance connects to exactly one Salesforce org, and you can't split it per site. If you run several country sites on one realm, they all land in the same org.

The setup checklist

This follows the official Configure Shopper Profile Sync guide, in the order that actually works, with the bits that confused me spelled out. Tick the boxes as you go (they don't survive a page refresh, so keep the tab open).

Why three duplicate rules?

Setting up six rules by hand feels like a lot for "sync my customers", so it helps to know what they are for. The recommended set covers three situations: a registered shopper, a guest shopper, and a registered shopper claiming an earlier guest record.

That last one is the interesting case. A shopper checks out as a guest, and Order Management creates a Person Account for that order. A month later the same person registers on your storefront. Without the claim rule you end up with two Person Accounts for one human. With it, the sync finds the guest record, links it to the new shopper and updates it instead.

flowchart TD
    R[Registered shopper
arrives from Commerce] --> M{Duplicate rules
find a match?}
    M -->|"Already linked"| U[Update that
Person Account]
    M -->|"Guest record from
an earlier order"| C[Claim it and link
to the shopper]
    M -->|"No match"| N[Create a new
Person Account]

If your org already has Person Accounts from somewhere else, these rules are also what stops the first sync from flooding it with duplicates. Worth testing on a sandbox with realistic data before production.

What about b2c-crm-sync?

If you are starting fresh, go native. If you already run b2c-crm-sync, it is worth looking at what you actually use, because the two don't cover exactly the same ground:

	b2c-crm-sync	Shopper Profile Sync
Support	Community project, no official support	Salesforce feature, supported
Setup	Node CLI, SFDX, OCAPI and WebDAV permissions, JWT certificates, Account Manager client	Connect in Business Manager, rules in Core
B2C Commerce API	OCAPI Shop and Data APIs (deprecated)	Built in, nothing to configure
Customer model	Person Accounts or Accounts and Contacts	Person Accounts only
Extras	Order on Behalf, agent password reset, address books, promotions view	Profile fields
Topology	Multiple instances, customer lists and sites	One instance to one org
Maintenance	Yours	Salesforce's

There is one more reason to move: OCAPI. b2c-crm-sync talks to B2C Commerce through the OCAPI Shop API and Data API, and OCAPI was marked deprecated in April 2026. It still gets support and security fixes, but no new features, and SCAPI is where everything new lands. The README promises a port to the new APIs "in a future release", and with the project quiet for three years, I wouldn't wait for it.

If you only use b2c-crm-sync to get profiles into Core, Shopper Profile Sync replaces it with a lot less to maintain. There is no switch that migrates you, though. The move is a data job, and it's the next section.

Moving from b2c-crm-sync

The two tools decide who owns a record by looking at different fields. b2c-crm-sync manages the Person Accounts that have its B2C_* ID fields filled in. Shopper Profile Sync manages the ones that have its Commerce reference fields filled in. So the move comes down to copying the IDs from the old fields into the new ones and blanking the old ones. Ownership changes hands one shopper at a time.

Why copy at all, instead of letting the first sync figure it out? Because of the registered shopper matching rule. It matches on Commerce Customer Reference and Commerce Organization Reference, exact. If those are already filled in when you turn on Auto-Sync, the first full sync finds every existing Person Account and updates it. Skip the copy, and you're counting on the broad email rule to find them, while b2c-crm-sync still thinks they're its own. Two integrations writing to the same record is not a fun afternoon.

b2c-crm-sync field (on the Person Account)	Shopper Profile Sync field
`B2C_Customer_ID__pc`	Commerce Customer Reference
`B2C_Customer_No__pc`	Account Number
`B2C_CustomerList_ID__pc`	Commerce Group Reference
None, it's a constant: your realm and instance, as `<realm>_<instance>`	Commerce Organization Reference

Note the __pc. b2c-crm-sync defines these fields on Contact, so on a Person Account they show up with the __pc suffix, and that's what you select in Data Loader. B2C_Site_ID__pc and the B2C_CustomerList__c lookup have no counterpart. Keep them or clear them, the new sync doesn't care.

The order I'd follow:

Rehearse on a sandbox with a copy of real data. Not production, not even "just to see".
Switch b2c-crm-sync off on both sides. In B2C Commerce, turn off the b2ccrm_syncIsEnabled site preference or take int_b2ccrmsync off the cartridge path. In Core, deactivate its B2C Instance and B2C Customer List records so its flows stop calling out.
Get temporary edit access to the Commerce reference fields. They are system-managed and read-only, even for admins with field-level edit access. Shopper Profile Sync comes with a system permission for exactly this. Search the system permissions for "Shopper Profile Sync" and add it to your user through a permission set or your profile.
Run the data job. Export the Person Accounts where B2C_Customer_ID__pc isn't blank, only for the customer list of the instance you're pairing. Fill in the new columns, blank the old ones and run an update with Data Loader using the Bulk API. Keep the export file. It's your undo button.
Remove the temporary permission, so the fields go back to being system-only.
Set up Shopper Profile Sync with the checklist above and turn on Auto-Sync last. Compare the Person Account count before and after the first sync. It should grow by roughly the number of shoppers b2c-crm-sync never synced, not double.
Clean up later: the Account Manager API client, the OCAPI settings, the connected app, and the b2ccrm_* custom attributes on customer profiles.

What you give up: b2c-crm-sync's quick actions on the Contact (Order on Behalf, agent password reset, the active promotions view) stop working once you switch it off in step 2, and they need the customer ID you just blanked anyway. Shopper Profile Sync has no equivalent in Core. Agents can still shop on behalf from Customer Service Center in Business Manager, so check it covers your flows before step 4. And two setups have no clean path at all. If you use the Accounts and Contacts model, Shopper Profile Sync only works with Person Accounts. If you sync several instances into one org, only the shoppers of the paired instance move over.

When it doesn't sync

A few places to look, roughly in the order I'd check them:

The card itself. Last sync status and next scheduled sync answer most "where is my customer?" questions. Usually the answer is "the job hasn't run yet".
Initialization Pending. Almost always missing or inactive duplicate rules, or required mappings that aren't complete.
Some shoppers sync, some never do. Look at your Person Account validation rules and required fields. A validation rule that a Commerce profile can't satisfy (a mandatory phone number, say) rejects that shopper on every run. A required custom field needs a mapping or a default value.
No Shopper Profile Sync card. It's the feature switch.
The system job. It's called sfcc-sync-unified-shopper-profiles and shows up as a system job in Business Manager, so depending on your permissions you may not see it at all.

Wrapping up

Connect the two clouds, enable Person Accounts, set up the three matching rules and the three duplicate rules (with Report on), turn on Auto-Sync last, and you have a supported two-way profile sync without a single line of custom code. Just remember the asymmetry: Commerce creates and syncs on a schedule, Salesforce only updates and does it almost instantly.

Next up is Merchant Agent, which uses the very same Salesforce Connection. Happy syncing. 🔄

Logpush Jobs for SFCC eCDN: All you need to know

2026-09-16T00:00:00Z

If you want to know what is actually happening to your traffic on SFCC, the eCDN logs are where the truth lives. Who hit your site, from which ASN, with what bot score, which firewall rule fired. You can analyze it after the fact, or you can act on it. The hot topic right now is telling bot traffic apart from real shoppers, and these logs are the raw material for exactly that. You can even automate firewall rules based on them, but that is a whole other article: Bot Management Automation for SFCC eCDN with Logpush.

Today let's keep it simple: how to get those logs out of the eCDN and into an S3 bucket with a Logpush job.

I recorded a full walkthrough where I set one up on a sandbox using a free-tier AWS account. Setup to first log in under 16 minutes.

The good news: there is finally a UI

For a long time Logpush jobs could only be created through the API. As of a release or two ago, there is now a proper UI for it inside Business Manager, under Administration → Embedded CDN → Settings. On top of that, eCDN is now available on sandboxes, which means you can safely test all of this on a sandbox before you touch anything that matters.

Here is the shape of what we are building:

flowchart LR
    U[Shopper] --> E[SFCC eCDN
Cloudflare]
    E --> O[SFCC Origin]
    E -. logs .-> LP[Logpush job]
    LP --> S3[(Amazon S3)]

The eCDN sees every request, and Logpush quietly ships a copy of the log lines to your bucket. That is the whole idea.

First rule of Logpush: you only get two jobs

This is the constraint that shapes everything else, so let's get it out of the way early. You get a maximum of two Logpush jobs per zone. Two. That's it.

So spend them wisely. The split that makes the most sense:

flowchart TB
    Z[Your zone] --> J1[Job 1
HTTP requests]
    Z --> J2[Job 2
Firewall events]
    J1 --> A1[General traffic analysis
bot scores, ASNs, paths]
    J2 --> A2[Which firewall rules actually fire]

Job 1 for HTTP requests. This is your general traffic feed. Bot scores, client IPs, ASNs, paths, user agents, the works.
Job 2 for firewall events. This tells you which of your firewall rules are actually being triggered and what action was taken. That matters more than it sounds, because there is a hard limit of 500 firewall rules. A firewall-events job lets you see which rules earn their keep, so you can prune the ones that never fire and free up room.

Alright, let's build one.

Creating the job (the happy path)

New Logpush job. Pick your destination (I'm using Amazon S3, but pick whatever fits your stack). Then select the dataset: HTTP requests or Firewall events. We'll start with HTTP requests.

Point it at your bucket and give it a path. Small tip that saves future-you a headache: use the {DATE} placeholder in the path. Logpush creates a lot of files, and dumping them all into one flat folder gets messy fast. Something like logs/{DATE} keeps each day tidy.

Set the region to match your S3 bucket exactly (mine is Ohio). If these do not match, nothing works.

The two gotchas that will get you

Everything above is smooth. These two are where people (me included) lose ten minutes.

Gotcha 1: the ownership challenge hates the date placeholder

The UI hands you an AWS resource policy. Copy it, go to your bucket → Permissions → Bucket policy, and paste it in. It saves cleanly, no errors, looks great.

Then you hit Next and get "Failed to send ownership challenge."

The reason is that the S3 side does not accept the {DATE} placeholder during the ownership challenge step. Fix: edit the path, remove the placeholder, and try again. This time the challenge goes through and drops a small challenge file into your bucket. Open it, copy the token, paste it back into the UI, confirm, and you own the destination.

flowchart LR
    A[Paste bucket policy] --> B{Hit Next}
    B -->|"{DATE} in path"| C[Failed to send
ownership challenge]
    C --> D[Remove placeholder
retry]
    D --> E[Grab token
from bucket]
    E --> F[Confirm ownership]

Gotcha 2: your test traffic never reaches the eCDN

You create the job, it says pending, and now you want to see it flip to active. The only way is to actually push some logs through, which means generating real traffic.

So you open the storefront and browse around. And nothing happens.

Here is why: hitting the normal storefront URL goes straight to origin and skips the eCDN entirely. Open dev tools, look at the response headers, and you'll see no Cloudflare headers at all. No eCDN, no logs.

For sandboxes you need to browse through the my. host (the *.my.commercecloud.salesforce.com one). That request actually routes through the eCDN, and now your logs start flowing. Browse a few pages and give it a minute.

Filters: store what you need, not everything

When you name the job you get to choose all logs or filtered logs. Filter. Please filter.

Storing everything is overwhelming and eats space fast. Filtering lets you keep only what you care about. In the demo I filtered on two fields:

ClientRequestHost contains my sandbox host
ClientRequestPath contains /s/RefArch

Drop the static assets

Here is the filter that saves you the most, and the one I'd add to almost every HTTP-requests job: throw away the static content.

Think about what you actually want from these logs — page visits, who's hitting what, bot scores, ASNs. You do not care that a shopper's browser also pulled down forty CSS, JS, image, and font files to render that one page. But the eCDN logs every one of them. In practice static assets are the overwhelming majority of your log lines, which means most of your storage (and most of the noise) is spent on requests you'll never look at.

The cleanest way to cut them in one shot is to filter on the response content type:

EdgeResponseContentType contains text/html

This keeps full page loads and the AJAX controller fragments that make up a real session — the Cart-MiniCartShow record above is text/html, so it survives — while dropping CSS, JS, images, and fonts, none of which carry that type. A BotScore on a .woff2 tells you nothing the parent page request didn't already, so you lose no signal.

Two things to keep in mind before you commit to it:

It also drops JSON responses (SCAPI/OCAPI and JSON controller endpoints). That's fine for a storefront-traffic view. If you're specifically hunting API abuse, don't use this filter — or widen it.
It drops redirects and typeless responses too. Minor, but worth knowing if 3xx chains matter to you.

You also pick which fields to store. Grab the ones that actually help you reason about traffic and skip the noise. My default set:

ClientASN, ClientIP, ClientIPClass (who and from where)
ClientRequestURI, ClientRequestUserAgent (what and with what)
BotScore (the good stuff, more below)
RayID (so you can correlate with everything else)

I leave Cookies off. You almost never want that sitting in a bucket.

What a log line looks like

Logs land compressed as .gz. Unzip one and each line is a JSON object. There are a lot of fields, but only a handful do the heavy lifting for traffic analysis. Here is a trimmed record with the ones that matter most highlighted:

{
  "BotScore": 98,
  "BotScoreSrc": "Machine Learning",
  "ClientASN": 14340,
  "ClientCountry": "us",
  "ClientIP": "123.123.123.123",
  "ClientIPClass": "noRecord",
  "ClientRequestHost": "abcd-123.my.commercecloud.salesforce.com",
  "ClientRequestURI": "/on/demandware.store/Sites-RefArch-Site/en_US/Cart-MiniCartShow",
  "ClientRequestUserAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) ... Chrome/152.0.0.0 Safari/537.36",
  "EdgeResponseStatus": 200,
  "SecurityActions": ["log"],
  "SecurityRuleDescription": "Log Rule",
  "RayID": "a3caa7730c129682"
}

Show the full record — every field the eCDN captured

{
  "BotDetectionIDs": [],
  "BotScore": 98,
  "BotScoreSrc": "Machine Learning",
  "BotTags": [],
  "CacheCacheStatus": "dynamic",
  "CacheReserveUsed": false,
  "CacheResponseBytes": 4606,
  "ClientASN": 14340,
  "ClientCountry": "us",
  "ClientDeviceType": "desktop",
  "ClientIP": "123.123.123.123",
  "ClientIPClass": "noRecord",
  "ClientRequestBytes": 7798,
  "ClientRequestHost": "abcd-123.my.commercecloud.salesforce.com",
  "ClientRequestMethod": "GET",
  "ClientRequestPath": "/on/demandware.store/Sites-RefArch-Site/en_US/Cart-MiniCartShow",
  "ClientRequestProtocol": "HTTP/2",
  "ClientRequestReferer": "https://abcd-123.my.commercecloud.salesforce.com/s/RefArch/checked-silk-tie-25752235M.html?lang=en_US",
  "ClientRequestScheme": "https",
  "ClientRequestSource": "eyeball",
  "ClientRequestURI": "/on/demandware.store/Sites-RefArch-Site/en_US/Cart-MiniCartShow",
  "ClientRequestUserAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/152.0.0.0 Safari/537.36",
  "ClientSSLCipher": "ECDHE-ECDSA-AES128-GCM-SHA256",
  "ClientSSLProtocol": "TLSv1.2",
  "ClientTCPRTTMs": 5,
  "Cookies": {},
  "EdgeCFConnectingO2O": false,
  "EdgeColoCode": "IAD",
  "EdgeColoID": 1024,
  "EdgeEndTimestamp": "2026-09-17T19:52:55Z",
  "EdgePathingOp": "wl",
  "EdgePathingSrc": "undef",
  "EdgePathingStatus": "nr",
  "EdgeRequestHost": "abcd-123.my.commercecloud.salesforce.com",
  "EdgeResponseBodyBytes": 1758,
  "EdgeResponseBytes": 2636,
  "EdgeResponseCompressionRatio": 4.4920363,
  "EdgeResponseContentType": "text/html;charset=UTF-8",
  "EdgeResponseStatus": 200,
  "EdgeServerIP": "104.23.209.15",
  "EdgeStartTimestamp": "2026-09-17T19:52:55Z",
  "EdgeTimeToFirstByteMs": 85,
  "OriginRequestHeaderSendDurationMs": 0,
  "OriginResponseDurationMs": 74,
  "OriginResponseHeaderReceiveDurationMs": 73,
  "OriginResponseStatus": 200,
  "OriginTCPHandshakeDurationMs": 0,
  "OriginTLSHandshakeDurationMs": 0,
  "ParentRayID": "00",
  "RayID": "a3caa7730c129682",
  "SecurityActions": ["log"],
  "SecurityRuleDescription": "Log Rule",
  "SecurityRuleIDs": ["b93e6d91300e4784b024c4181axxyyzz"],
  "SecuritySources": ["firewallCustom"],
  "ZoneName": "abcd-123.my.commercecloud.salesforce.com"
}

The star of the show is BotScore. Cloudflare scores traffic from 1 to 99. Close to 99 means almost certainly a human. Close to 1 means almost certainly a bot. The record above sits at 98, so, real person. Pair the score with ClientASN, ClientCountry, and ClientIP and you have the ingredients for automated firewall rules that block the obvious bots. That is the "act on your logs" part I keep teasing.

If you also run the firewall-events job, each record tells you the Action taken, the RuleID, and the rule Description, so you can watch your rules do their job in real time.

So how do you actually analyze this?

One record is easy to read. You will never look at just one. A busy storefront produces millions of lines a day, and even filtered down to text/html a single day is hundreds of thousands of records spread across a pile of .gz files. Opening them by hand is not a plan.

The mental model that fixes this: S3 is a bucket, not a tool. It holds your gzipped JSON and does nothing else. To get answers out of it, you point a query engine at it.

Since the logs already live in S3, the natural choice is Amazon Athena. It runs plain SQL directly against the files in your bucket — no server to manage, you pay per query. Remember the {DATE} placeholder from earlier? This is where it pays off: partition the table by date and each query scans only the days you ask about instead of the whole bucket, which keeps it fast and cheap. (While you're there, add an S3 lifecycle rule to expire old logs so the bucket doesn't grow forever.)

And because the goal is spotting bots, one query does what no human could eyeball — group a day's traffic by ASN and surface the networks that are busy and score badly:

SELECT ClientASN,
       COUNT(*)      AS hits,
       AVG(BotScore) AS avg_bot_score
FROM   ecdn_http_requests
WHERE  date = '2026-09-18'
GROUP  BY ClientASN
HAVING AVG(BotScore) < 30     -- consistently bot-like
ORDER  BY hits DESC;

That list — noisy networks with low bot scores — is exactly the input for the automated firewall rules I keep promising.

Want charts instead of a SQL prompt? Put Grafana on top of Athena. Grafana draws the dashboards; Athena still does the querying underneath. You keep one copy of your data in S3 and get the visual view for free.

One shortcut worth knowing: if your organization already runs Splunk or Datadog, Logpush can push straight to them and you get their analysis views and dashboards out of the box — you may not need S3 at all. Worth it only if you're already paying for one; standing one up just for eCDN logs is overkill.

Whatever you pick, the shape is the same: cheap storage in S3, a query engine on top. Start with Athena, add Grafana if you want pictures, and reach for Splunk or Datadog only when they're already in the building.

One thing nobody warns you about: client IP and stacked CDNs

Here is a subtle one worth knowing before you build anything on top of these logs.

The Logpush schema is a fixed list of fields. There is no field for arbitrary request headers, and ClientIP is always the IP that connected to the eCDN. Normally that is your shopper, and life is good.

But if you put another CDN in front of the eCDN (a stacked setup, say Fastly or Akamai out front), the eCDN only ever sees the front CDN's edge IP. So ClientIP in your Logpush output becomes that edge IP, not the real shopper.

flowchart LR
    S[Real shopper
1.2.3.4] --> F[Front CDN
Fastly / Akamai]
    F -->|"eCDN sees
the front CDN IP"| E[SFCC eCDN]
    E --> O[Origin]
    E -. Logpush .-> L[(ClientIP = front CDN,
not 1.2.3.4)]

And because the schema has no slot for a custom header, you cannot recover the real shopper IP from eCDN Logpush, no matter how you name headers upstream. Anything that depends on the true client IP (IP-based rate limiting, geo blocking, bot score) gets fuzzy in a stacked setup, because the eCDN is scoring the front CDN, not the shopper.

The practical takeaway: if you run a stacked CDN, capture real client IPs at the outermost layer (the one that actually sees the shopper first). Keep the eCDN logs for what the eCDN genuinely observed: rule hits, paths, RayIDs, and edge behavior. They are still great for that.

Wrapping up

That is the whole thing. Two jobs per zone, one for HTTP requests and one for firewall events, filtered down to what you care about, landing in S3, with a query engine like Athena on top to make sense of it. Watch out for the date placeholder during the ownership challenge, and remember to send your test traffic through the my. host so it actually hits the eCDN.

Happy logging. 📦

SFCC Vibe Coding with an MCP Server

2025-12-11T00:00:00Z

At this point, it is hard to imagine SFCC development without using AI. It speeds things up significantly. Of course, you need to be careful with it, which is a separate "Vibe Coding" topic.

The specific challenge with SFCC Vibe Coding is that standard LLMs usually aren't very good with SFCC context.

To cover that gap, we can use an MCP Server. This allows the AI to actually understand our environment. 📖 Thomas Theunen describes this concept perfectly here.

I created a video guide on how to configure this and a demo showing Copilot automatically fetching error logs to resolve issues.

MCP Server: https://sfcc-mcp-dev.rhino-inquisitor.com (Creator: Thomas Theunen)

There are some security concerns:

dw.json — I'd suggest creating a dedicated SFCC account/credentials with a limited access to sandboxes only, maybe DEV, but definitely not STG/PRD. It might be one shared account per project/team.
OCAPI Client — Same here, a dedicated API Client per project with a limited access to sandboxes (and maybe DEV) only.
3rd-party MCP Server — While MCP Server from Thomas sounds reliable, it is still 3rd-party with unexpected updates. And enterprise security models can be against it. In this case we can clone it (since it's under MIT).

SFCC Field Notes - Oleksandr Katerynchuk

Bot Management Automation for SFCC eCDN with Logpush

The score is in the logs, not in the rules #

What about the new Known Bot field? #

The idea in one picture #

What the POC does #

The numbers depend on your Logpush filter #

Why IPs and not ASNs #

Custom rules or rate limiting rules? #

Why a job on SFCC is not the real-world shape #

Two loops: one creates, one cleans up #

Start with Log. Always. #

The business owns the cutoff #

Before you build this #

Third-party bot protection #

Wrapping up #

Shopper Profile Sync for SFCC and Salesforce

Shopper Profile Sync or Unified Profile Sync? #

How it works: two directions, two mechanisms #

The fine print behind "two-way" #

Before you start #

The setup checklist #

Why three duplicate rules? #

What about b2c-crm-sync? #

Moving from b2c-crm-sync #

When it doesn't sync #

Wrapping up #

Logpush Jobs for SFCC eCDN: All you need to know

The good news: there is finally a UI #

First rule of Logpush: you only get two jobs #

Creating the job (the happy path) #

The two gotchas that will get you #

Gotcha 1: the ownership challenge hates the date placeholder #

Gotcha 2: your test traffic never reaches the eCDN #

Filters: store what you need, not everything #

Drop the static assets #

What a log line looks like #

So how do you actually analyze this? #

One thing nobody warns you about: client IP and stacked CDNs #

Wrapping up #

SFCC Vibe Coding with an MCP Server

The score is in the logs, not in the rules

What about the new Known Bot field?

The idea in one picture

What the POC does

The numbers depend on your Logpush filter

Why IPs and not ASNs

Custom rules or rate limiting rules?

Why a job on SFCC is not the real-world shape

Two loops: one creates, one cleans up

Start with Log. Always.

The business owns the cutoff

Before you build this

Third-party bot protection

Wrapping up

Shopper Profile Sync or Unified Profile Sync?

How it works: two directions, two mechanisms

The fine print behind "two-way"

Before you start

The setup checklist

Why three duplicate rules?

What about b2c-crm-sync?

Moving from b2c-crm-sync

When it doesn't sync

Wrapping up

The good news: there is finally a UI

First rule of Logpush: you only get two jobs

Creating the job (the happy path)

The two gotchas that will get you

Gotcha 1: the ownership challenge hates the date placeholder

Gotcha 2: your test traffic never reaches the eCDN

Filters: store what you need, not everything

Drop the static assets

What a log line looks like

So how do you actually analyze this?

One thing nobody warns you about: client IP and stacked CDNs

Wrapping up