Most Brave aficionados will have read about the fundamentals of the BAT ecosystem, but what exactly does the full ad serving flow look like?
- First, the advertiser becomes verified, similar to how a publisher or creator verifies (with the wallet) with the Brave platform.
- On the server side, the ad inventory is flighted into a catalog of URLs.
- The ad catalog is then pushed to devices (by language & region).
- The catalog functions as a local ad server on the user’s device. This is a distinct difference from the conventional ad serving mechanism (whereby the browser requests ads from a 3rd party server for every page load, which comes with a severe performance tax and significant data leakage).
- Local machine learning, intent signals and the browser corpus progressively train on the user’s attention as they browse (note, that this data does not leave the device; again a key difference to the prevailing ad model).
- At the calculated opportune time, the platform activates a local auction layer and bid-matches options from the inventory catalog that fit the attention-experience context.
- The winning ad is presented to the user in the form of a native push notification.
- The native push notification contains a call to action, and is only presented when deemed viewable (based on the user’s attention baseline).
- If the user engages with the notification, a new tab displays which either displays the landing page or a rich media creative (HTML5 embeddable).
- Hopefully, the user converts on the opportunity (be that a transaction, lead generation, etc.)
- Analytics will be measured using Anonize2 zero-knowledge proof protocols (which allow for the user to remain anonymous to the advertiser).
- Analytics are presented in aggregate in dashboards within the advertiser interface, and supposedly, APIs will also be available.