Does Split Work in China? PIPL Cross-Border, Automated Decisions & Data Residency
Split — now Harness Feature Management & Experimentation — evaluates your China users' targeting attributes offshore to decide which feature or experiment each one sees, and streams impressions back. That is a PIPL cross-border transfer and Article 24 automated decision-making, not a speed problem — a compliance-first look at keeping the decisioning and user data in-country.
Does Split work in China?
Reaching Split’s SDK is never the question — the question is that Split (now Harness Feature Management & Experimentation) evaluates your China users’ attributes offshore to decide what each of them sees.
To pick a feature or experiment variant, Split takes a targeting context — a user key plus attributes such as plan, device, geography or custom traits — and streams back impressions that record what each user was shown. In remote evaluation that context is sent to Harness’s offshore service; even in local evaluation, per-key segment checks and impressions still leave the device. For your China users that is both a PIPL cross-border transfer of personal information (Articles 38–40) and an Article 24 automated decision about what each person sees. The lawful lever is to keep flag-evaluation and user data in-country — run Split’s customer-deployed components inside China or a licensed domestic alternative, send the least identifying context, and honor the Article 24 right to a non-profiled option — not to make the offshore SDK reachable.
Which duty bites first depends on what you send and who your users are — a risk map to settle with counsel. Our China team can map your exposure →
What Split's own documentation says about China
| Fact | Primary source |
|---|---|
| In remote evaluation, Split sends your user’s targeting context to its offshore service to decide what they see. Split’s own SDK documentation states that “the SDK sends the SDK key and the target (key, trafficType, and attributes) to the Remote Evaluator in FME cloud, which evaluates every flag for that target and returns the results in one response.” That key and those attributes are personal information, and the evaluation — the decision about what each user sees — happens offshore. | Split / Harness FME — SDK evaluation modes (developer.harness.io), retrieved 2026-10-10 |
| Impressions — records of which user saw which treatment — flow to Harness’s servers, even through the component you self-host. Split’s Synchronizer, a component you run in your own infrastructure, “coordinates feature flag and segment data between” Harness FME servers and your SDKs and sends “records of flag evaluations” to Harness servers for analytics. Self-hosting controls what is sent, but the managed service of record stays offshore. | Split / Harness FME — Split Synchronizer docs (developer.harness.io), retrieved 2026-10-10 |
| A feature flag or experiment is automated decision-making under PIPL Article 24. Deciding which feature, variant or personalized experience each user receives from their attributes or cohort is profiling. PIPL Article 24 requires transparency and fairness, a way for the individual to refuse, and — where the decision rests on profiling — an option not to be targeted by their personal characteristics. | Personal Information Protection Law of the PRC, Article 24, retrieved 2026-10-10 |
| Sending China users’ context and impressions to a US service is a cross-border transfer, and storage may have to stay in-country. As the handler you owe notice, a separate consent and a transfer mechanism under PIPL Articles 38–40. For a critical information infrastructure operator or high-volume handler, that data must be stored in the mainland under Cybersecurity Law Article 39 (formerly Article 37). | PIPL Articles 38–40; Cybersecurity Law Article 39 (formerly Article 37), retrieved 2026-10-10 |
Sources verified by the 21YunBox compliance team on 2026-10-10.
For a mainland-China audience, the question about Split is not whether its SDK can be reached — it is what happens to the data you hand it. Split, acquired by Harness in 2024 and now Harness Feature Management & Experimentation (FME), decides which feature or experiment each visitor sees from a targeting context — a user key plus attributes (plan, device, geography) — and streams back impressions recording what each user saw. In remote evaluation that context is sent to Harness’s offshore service; even in local evaluation, impressions and per-key segment checks still leave the device. For your China users that is two duties: a PIPL cross-border transfer of personal information (Articles 38–40) and an Article 24 automated decision about what each person sees — plus consent (Articles 13/23) and in-country storage for a CIIO or high-volume handler. Reachability is not the axis; the data and the decision are.
Split in China at a glance
| What decides it | In Split's own terms — and China's law |
|---|---|
| What you send it | A targeting context — a user key plus attributes (plan, device, geography, custom traits) — and the impressions that record what each user was shown. Keys and traits tied to behavior are personal information. |
| Where it is evaluated and stored | In remote evaluation the context goes "to the Remote Evaluator in FME cloud"; impressions and per-key segment checks reach Harness's servers, hosted on AWS in the United States. None of it sits in mainland China — so using it on China users is a cross-border transfer (PIPL Articles 38–40, 数据出境). |
| What it decides | Which feature, variant or personalized experience each user receives, from their attributes or cohort. That is automated decision-making and profiling under PIPL Article 24 — which requires transparency and fairness, a way to refuse, and an option not to be targeted by one's personal characteristics. |
| Consent and residency | Behavioral tracking and experimentation need a real, separate consent (PIPL Articles 13/23) — a buried "by using this product" is not enough. A critical information infrastructure operator or high-volume handler also owes in-country storage (Cybersecurity Law Article 39, formerly Article 37). |
| Is it reachable? | Yes — the SDK and API load from China. But reachability is not the axis. The lawful path is to keep flag-evaluation and user data in-country (self-host Split's customer-deployed components or a licensed domestic engine), minimize the context you send, honor the Article 24 opt-out, and ICP-file the app that consumes the decisions. |
What you actually send — your users’ attributes and behavior
Start with what crosses the wire, because that is where the exposure lives. To return a treatment, Split evaluates a targeting context: a user key and its attributes — strings, numbers, dates, booleans — that describe the person being evaluated (plan, tier, device, geography, or any custom trait you attach). How much of that leaves China depends on the evaluation mode. In remote evaluation, Split’s documentation says, “the thin SDK does not download the rollout plan at all” and instead sends the key and the target attributes “to the Remote Evaluator in FME cloud, which evaluates every flag for that target and returns the results in one response.” In local evaluation the server-side SDK keeps the rollout plan in memory and decides in-process — attributes “never leave the application” — but even then segment membership “is checked against the FME servers one key at a time,” and the impressions that log which user saw which treatment are posted off the device.
Those impressions are the second half. Split’s Synchronizer — a component you can run in your own infrastructure — “coordinates feature flag and segment data between” Harness FME servers and your SDKs, and forwards “records of flag evaluations” and .track events to Harness’s servers for analytics and experimentation. Because Split is feature-flagging and experimentation rather than a profile-building customer-data platform, it does not assemble a permanent unified profile of each person — but the impression and event stream still accumulates offshore as a growing behavioral record of your China users, keyed to their identifiers.
It’s a cross-border transfer — and an automated decision — under PIPL
Run Split on your China users and you trigger two distinct duties at once. First, the cross-border transfer. The targeting context you send to evaluate a flag and the impressions that flow back are personal information, and Harness’s service sits on AWS in the United States, with no mainland-China region. Moving that data out of China is a transfer the Personal Information Protection Law governs under Articles 38–40 (数据出境): you — the handler, not the vendor — must give notice, obtain a separate consent, and clear a transfer mechanism (a CAC security assessment, the CAC standard contract, or certification). Where you are a critical information infrastructure operator or a high-volume handler, that personal information must instead be stored in the mainland — PIPL Article 40 and Cybersecurity Law Article 39 (formerly Article 37) (the 2025 Cybersecurity Law amendment, in force January 1, 2026, renumbered the data-localization article from 37 to 39, substance unchanged) — a residency duty no US region can meet.
Second, and the prong most teams miss: a feature flag or experiment is automated decision-making. Deciding which feature, variant or personalized experience each user receives from their attributes or cohort is profiling, and PIPL Article 24 governs exactly that. It requires that automated decisions be transparent and fair, that the individual can refuse, and — where a decision is based on profiling — that you offer an option not to target them by their personal characteristics. Targeting a cohort, running an experiment on a segment, or personalizing from a trait is squarely within Article 24. Add the consent basis: behavioral tracking and non-essential experimentation need a real, informed, separate consent under Articles 13/23, not a line buried in a terms-of-use page.
Reaching the SDK isn’t the question — keeping the decisioning in-country is
Because Split loads from China, it is tempting to treat this as a connectivity exercise. It is not. The lever is to keep the decisioning and the user data on an in-country path. Split helps here more than most: its server-side SDKs evaluate in-process so raw attributes can stay inside your own systems, and it ships customer-deployed components — its Synchronizer, its Evaluator, and a self-hosted on-cluster evaluation and synchronization component — that you can run on your own infrastructure in China so flag decisions and identifiers never have to leave the mainland to be computed. What self-hosting those components does not do by itself is move the managed service of record: impressions, events and per-key segment checks still reach Harness’s offshore servers. So the lawful design keeps evaluation in-country, sends the least identifying context possible (pseudonymous keys, no raw email or ID where a flag does not need them), governs the residual transfer of impressions and events under PIPL, and honors the Article 24 right to a non-profiled option — or routes China users to a licensed in-country experimentation alternative. What it is never is a hidden path that ships the same data offshore anyway.
This is a risk map, not a verdict. Whether the cross-border rules, an Article 24 obligation, a consent gap, or a data-localization duty applies to you depends on what context you send, what you decide from it, your role, and your data volumes — worth settling the specifics with counsel before you ship.
The lawful path — map, localize, deliver
You keep building on Split. 21YunBox adds the compliance layer its offshore service cannot, in three moves:
- Map — inventory the targeting context and events your Split setup sends, what personal information they carry, where each flag is evaluated and where impressions land, how those decisions shape what China users see, and the consent and Article 24 basis you rely on.
- Localize — keep China-user flag-evaluation and data on the mainland: run Split’s customer-deployed components in-country, or route China users to a licensed domestic experimentation engine; minimize and pseudonymize the context sent offshore; and honor the Article 24 right to refuse profiling and the Articles 13/23 consent.
- Deliver — the app or site that runs the flags and consumes the decisions carries an ICP filing duty and needs compliant, in-country delivery. The 21YunBox Optimizer provides that, in front of the stack you already run — no rebuild, no migration, no second codebase.
The goal is simple: Split runs legally and compliantly for your users in China. 21YunBox never uses or suggests circumvention of any kind. We are a compliant overlay and partner to Split, not a replacement for it.
Related reading:
- Cross-border data transfers under PIPL
- China’s Cybersecurity Law and data localization
- The data export security assessment measures
- How to get an ICP filing for China
