CONCEPT Cited by 1 source
Segmented partner data access tiering¶
Definition¶
A segmented partner data access tiering is the design recognition that a B2B data provider's partner base does not have uniform access needs, and that any single access pathway (API / UI / SFTP / dashboard) will under-serve at least two of three typical partner segments. The solution is to pick a protocol whose client ecosystem covers all segments, rather than stand up separate subsystems per segment.
The canonical three-segment framing surfaces in Zalando Partner Tech's 2025-07 Delta Sharing post:
- Large partners — "well-oiled machines". Want programmatic access through secure, automated pipelines. Technically sophisticated; need raw data flowing into their existing analytics infrastructure.
- Medium partners — "hybrid world". Comfortable with dashboards and periodic pulls; not equipped for real-time streaming. Want flexibility without overwhelming complexity.
- Small partners — "spreadsheets and ad-hoc". Simplicity and accessibility trump technical sophistication. Need familiar tools.
Why uniform access fails¶
If a provider offers only a REST API:
- Large partners love it (fits their pipeline stack).
- Medium partners can use it but need to build client code and dashboards on top.
- Small partners are blocked or frustrated (they need a spreadsheet, not an API).
If a provider offers only a self-service portal with CSV downloads:
- Small partners love it.
- Medium partners can use it but the UI isn't designed for heavy pulls.
- Large partners are blocked (cannot script the UI; pulls are ratelimited).
The Zalando pre-Delta-Sharing state had all of {APIs, SFTP, S3, CSV downloads, self-service reports} — each serving some partners poorly; together producing a fragmented mess where partners allocated ~1.5 FTE/month just to consolidate across them.
Why a protocol with a broad client ecosystem wins¶
systems/delta-sharing has clients for:
- Spark / pandas — fits large-partner pipelines.
- Power BI / Tableau — fits medium-partner BI stacks.
- Excel — fits small-partner spreadsheet workflows.
One share, one credential, one governance model → three partner tiers served simultaneously. The client-ecosystem breadth is the load-bearing reason an open protocol beats a proprietary alternative (patterns/open-protocol-over-proprietary-exchange).
Beyond client ecosystem: access-pattern tiering¶
Partners within the same segment can still have divergent access-pattern needs:
- Real-time insights — react to market changes.
- Historical analysis — terabyte-scale trend analysis across years.
- Incremental updates — keep synced systems fresh.
- Batch processing — periodic bulk consumption aligned with internal pipelines.
A zero-copy protocol like Delta Sharing (concepts/zero-copy-data-sharing-protocol) handles all four naturally: live reads satisfy real-time; time travel satisfies historical; file-reference-based protocol satisfies incremental; bulk range reads satisfy batch.
Shape of governance across tiers¶
Different partner tiers may warrant different governance:
- Large partners often have their own security / data-access compliance regime; can handle their own audit trails.
- Medium partners may need provider-side audit trails exposed to them.
- Small partners need simple, self-explanatory access with minimal config.
The three-tier framing is a lens for what governance surface to expose per segment, not just what client to support.
Tier → access-surface mapping (Zalando example)¶
| Tier | Volume | Client stack | Access pattern | Onboarding |
|---|---|---|---|---|
| Large | TB / history | Spark / pandas | Programmatic | Activation-link + automation |
| Medium | GB / weekly | Power BI / BI | Dashboard + pulls | Activation-link + guided setup |
| Small | MB / ad-hoc | Excel | Spreadsheet | Activation-link + one-pager |
All three use the same Delta Sharing protocol + same Share + Recipient primitives (patterns/recipient-per-partner-share-per-dataset-group) + same concepts/activation-link-credential-bootstrap. The client and docs differ per tier; the backend is identical.
Seen in¶
- sources/2025-07-07-zalando-direct-data-sharing-using-delta-sharing-introduction-our-journey-to-empower-partners — Zalando Partner Tech explicitly frames partner segmentation as the driving criterion for picking Delta Sharing. Quote: "Our evaluation criteria were ambitious but necessary. The solution needed to align with Zalando's broader data strategy while being cloud-agnostic enough to work with partners' varied infrastructure. It had to support the full spectrum of partner ecosystems, from small businesses running on spreadsheets to enterprise operations with sophisticated data pipelines." Load-bearing reasoning: single protocol with a broad client ecosystem > three separate subsystems per tier.
Related¶
- systems/delta-sharing — protocol chosen specifically for its broad client ecosystem coverage.
- systems/zalando-partner-data-sharing-platform — Zalando instance that serves all three tiers.
- concepts/zero-copy-data-sharing-protocol — enables access-pattern tiering within a single protocol.
- concepts/partner-portal-interactive-planning — companion concept for the UI/interactive surface partners see alongside direct data access.
- patterns/open-protocol-over-proprietary-exchange — load-bearing architectural axis that a broad client ecosystem depends on.
- patterns/recipient-per-partner-share-per-dataset-group — deployment primitive that works across all three tiers.