Data Portability and Platform Attribution Explained

User Data Portability and Platform Attribution Are Different Questions

Data portability and platform attribution can coexist. Portability asks whether a person can obtain and reuse data across services. Attribution asks whether the source travels with the data and how that source is represented. Neither question alone decides ownership, processing permission, downstream use, privacy, endorsement, or contract rights.

The Strava-Garmin dispute made these concepts look mutually exclusive. They are better designed as separate layers.

Begin with the data path

Consider an activity recorded by a wearable, synchronized to its device platform, transferred into a social fitness service, analyzed by a coaching application, and exported into a shareable image.

flowchart LR
    A["Person performs activity"] --> B["Device records signals"]
    B --> C["Device platform stores activity"]
    C --> D["Social platform imports activity"]
    D --> E["Coaching service derives insight"]
    D --> F["User exports or shares"]
    B -. "Source provenance" .-> C
    C -. "Source provenance" .-> D
    D -. "Processing provenance" .-> E
    D -. "Processing provenance" .-> F

Several parties contributed. The person generated the activity and personal context. The device captured signals. The device platform normalized and transmitted them. A second platform organized, displayed, and combined them. Another service may have derived an insight.

"Whose data is it?" is therefore too compressed to guide product design.

Separate the questions

A strong user statement can answer the access question while leaving every other row unresolved.

Portability has a defined legal scope

The UK's Information Commissioner's Office explains that the right to data portability allows individuals to receive certain personal data in a structured, commonly used, machine-readable format and request direct transmission in applicable circumstances.

The right is not universal across every jurisdiction, data type, source, and processing purpose. The ICO guidance describes conditions involving the lawful basis, automated processing, data provided by the person, and the rights of others.

A product should not turn "users should control their data" into a claim that every field can be copied, disclosed, or commercially reused without restriction.

Attribution preserves source without taking away access

Garmin's June 30, 2025 API Brand Guidelines require attribution for Garmin device-sourced data across displays, exports, APIs, derived uses, and social assets.

Those requirements can impose real implementation and design costs. They do not logically erase the user's interest in accessing the underlying activity. A structured export can include both the activity data and a source field. A share card can display the activity while preserving a proportionate source label.

The design dispute concerns placement, prominence, repetition, downstream enforcement, brand treatment, and contractual authority. It is not resolved by declaring either that the platform owns everything or that user involvement removes every source condition.

Provenance is more useful than a logo alone

The W3C PROV-O Recommendation provides a vocabulary for entities, activities, derivation, primary sources, and attribution. It demonstrates that provenance can be represented as structured information rather than only a visual badge.

A portable activity record can preserve the recording device, original service, timestamp, units, transformations, manual edits, derived metrics, and export service. That trail supports trust and debugging.

A logo may help a human recognize a source. It cannot replace the machine-readable record needed across APIs and exports.

Downstream platforms also impose rules

Strava's current API agreement restricts uses of Strava data and requires compliance with its brand guidelines. Its developer guidelines govern Strava marks and data links.

This does not by itself answer whether Garmin's 2025 policy was proportionate or contractually required in a specific relationship. It does show that attribution and downstream control are ecosystem questions, not a one-company invention.

A platform opposing an upstream requirement should explain the difference between the requirement it imposes and the requirement it resists. The distinction may be scope, placement, transformation, competition, user choice, or contractual history. Ignoring the comparison leaves the audience to infer hypocrisy.

Design for portability with provenance

The export should use a documented schema and preserve stable identifiers, time zones, units, source fields, edit history, and deletion semantics. It should avoid forcing a person to surrender unrelated data.

The receiving service should disclose which fields it imports, how it uses them, which source metadata it retains, and whether later deletion or revocation propagates. It should distinguish an original measurement from a derived score.

The visible interface should make attribution accurate and proportionate. A source label should not imply endorsement of downstream analysis. A derived insight should identify both the original source and the service that created the interpretation when that distinction matters.

The legal and contractual review should be specific to the jurisdiction, agreement, data category, and transfer path. Product teams should not infer permission from technical access.

The better principle

People should be able to understand and reuse applicable data about their activity. Systems should preserve where the data came from and how it changed. Platforms should explain the permissions and obligations governing that movement.

That principle does not guarantee agreement about a particular logo or API term. It produces a cleaner argument than forcing a choice between "the user's data" and "the platform's attribution."

[[What Happens When an API Policy Changes Under Your Product]] shows how to review a new requirement. [[How to Communicate a Partner Dispute Without Making It Worse]] shows how to explain the conflict without collapsing the concepts.

This page is general product guidance, not legal advice. It reflects sources reviewed on July 27, 2026. AI assistance was used for research organization, drafting, and validation. Publication remains unauthorized.