Skip to content

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.

(Source: sources/2025-07-07-zalando-direct-data-sharing-using-delta-sharing-introduction-our-journey-to-empower-partners)

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.
Last updated · 550 distilled / 1,221 read