Privacy

In short

yeld is a contextual ad network. An ad is matched to the app it appears in and to hints the publisher chooses to send — not to the person looking at it. There is no behavioral profile, so there is nothing to opt out of, and nothing to sell.

Two groups of people are involved, and they are treated differently. Account holders — publishers and advertisers — give us an email address and business details. End users of a publisher's app give us nothing directly; we see only what the publisher's integration sends, described below.

What an ad request sends

This is the complete list. Every field is either supplied by the publisher's integration or is standard HTTP request metadata.

App ID

The publisher's public app identifier, e.g. app_k3j9x2m1p4q8. Identifies the app, never a person.

Placement key

Which standard slot made the request — bottom-banner, sidebar, or in-content. Used for matching and for the publisher's own reporting.

Context

Optional hints chosen by the publisher: { category?, event?, page?, keywords? }. Publishers are instructed never to place personal data or user-generated content in these fields. If one arrives anyway, it is the publisher's integration that put it there.

Session ID

A random string generated in the browser and kept in localStorage. It is not derived from anything about the device or the person, is not shared across sites, and is used only to avoid showing the same ad repeatedly and to detect duplicate clicks. Clearing site data ends it permanently.

Request metadata

The ordinary metadata any web request carries — IP address, Origin, timestamp. The origin is checked against the app's registered host; the rest is used for abuse and invalid-traffic detection and is not used to build a profile.

Events

An ad request row, an impression row when an ad is served, and a click row when the unit is clicked — each carrying the fields above plus the campaign involved. These exist so advertisers can be billed correctly and publishers paid correctly.

What yeld does not do

• No device or browser fingerprinting.
• No third-party cookies.
• No cross-site or cross-app behavioral profiles.
• No reading of user content, page contents, or the DOM around the ad unit.
• No IP-derived identity graphs, and no attempt to resolve a session to a person.
• No sale of personal data, and no sharing of end-user data with advertisers.
• No advertiser-supplied scripts, pixels, iframes, or markup — yeld controls all rendering.

Advertisers submit text and an optional logo. Because they cannot ship code into the unit, no third party can observe a publisher's users through yeld — including the advertiser whose ad was shown.

Why it is kept, and for how long

Ad requests, impressions, clicks, and ledger entries are the accounting record of the network: they are what makes a click billable exactly once and an earning verifiable. They are retained while they are needed for reporting, billing, payouts, and dispute resolution, and are reported in aggregate — impressions, clicks, spend, earnings — in publisher and advertiser dashboards.

Retention periods are not yet fixed. A finished policy must state them explicitly; treat their absence here as an open item rather than a claim that nothing expires.

Publisher responsibility

yeld's contextual design is intended to keep a publisher's obligations small, but it does not remove them. If you embed the unit, you remain responsible for your own users' notices, disclosures, and consents under the law that applies to you and to them, and for not forwarding anything personal in the context field. See the context rules and the terms.

Contact

Questions, corrections, or deletion requests: privacy@yeld.dev. Account holders can also raise anything through the dashboard.