ambiretech / adex-adview-manager Goto Github PK

If the user moves their mouse over the ad for more than a certain threshold (e.g. 500ms), record it as an "engagement" and send an event to the validator

Note: there is no spec in the protocol for this - it's a new concept

add a targeting tag automatically (if an option is requested) based on navigator.language

there should be an option to encode information in a query parameter of the the target URL, such as publisherAddr, campaign.id and unit.id

Encoding the prefix of those things might be sufficient, cause we can infer the rest, especially we only have to select from the advertiser's own campaigns; gzip might help too

see triggers and visibilitySpec at https://amp.dev/documentation/guides-and-tutorials/learn/a4a_spec

in other words, implement a mechanism that allows specifying when an impression should be registered

main-browser: auto-collapse if we detect that we're running in an iframe

This will ensure that the referrer restriction (#53) actually limits which websites you can place the adview on

This will be tough since we're already running in an iframe and we don't have access to the parent iframe

similar to #40: instead of falling back to specific HTML, start header bidding using prebid.js

The adview manager should be able to automatically add UTM tags if enabled in the campaignSpec (campaignSpec.autoUTM: { enabled: true }, so that options can be added if needed)

This cannot be implemented on another level, since the AdView manager is the only component that knows the selected campaign

However, it cannot be an adview setting (must be an option in the campaign) cause it's something that the advertiser should control

https://www.bluleadz.com/blog/what-are-utm-tags-and-how-to-use-them

NOTE: UTMs used to be implemented in the Platform by directly sticking them to each ad unit when creating it. However, since there's no context of campaign that way, we are reviving this issue for the AIP31 implementation (2020-Q2-OKR1)

add the ability to auto-select ad size depending on the aspect ratio and absolute size of the slot you're trying to use

could be somewhat similar to the IAB responsive formats

Currently, the internal size is set to "width=100%"

However, chromium warns:

	[Intervention] An <img> element was lazyloaded with loading=lazy, but had no dimensions specified. Specifying dimensions improves performance. See https://crbug.com/954323

Find a way to specify the size while still overriding it (perhaps with style) to be width: 100% and height: auto

Instead of using our own moonicorn gateway, use the cloudflare gateway

however, first check if it works properly - sometimes IPFS takes a while to sync

related to #17 but simpler and hardcoded

This could work nicely: https://stackoverflow.com/a/38873788 - it is the same logic that jQuery uses

This is also somewhat overlapping with WAIT_FOR_IMPRESSION in cfg/main

by using the code defined by the market in lib/, we can request certain validaors directly and apply the status filter on a randomly chosen campaign until we have an Active/Ready one

this snippet will reverse the whole array on each call.
https://github.com/AdExNetwork/adex-adview-manager/blob/1335c19c8b0a832ec2cc3b1bdf7b54b8f584f4e3/src/main.ts#L137

We need to implement Interactive & Rich HTML5 ads format support as some advertisers requested it and all leading ad networks support it. HTML5 ads will allow advertisers to implement real CTA buttons or creative animations, etc.

This will also apply to fallback tags by default

Double-check the campaign status with the validators and potentially ethereum

This should be done by getting the latest messages and computing the status via the same code used in the market itself

part of https://github.com/AdExNetwork/aips/issues/31

function signature should be: [min, max, value]

See https://github.com/AdExNetwork/aips/issues/15

We need an API that would allow the profile.adex.network origin to set preferences (targeting tags in grouped format) in the localStorage

This should also set new targeting variables as per targeting and bidding (originally AIP31)

Variables to be added to the AdView and the spec:

• adView.hasCustomPreferences
• adView.preferredCategories
• adView.excludedCategories

Excluding campaigns will not be a part of the targeting system, it will be handled separately

Consider a new integration option, where you insert a JS in your page and also insert <div>s for every placement. This is actually how most ad networks work.

Pros:

• no <iframe>, which also makes it friendlier to Google Ad Manager
• we can vaguely control the placement we do that via 79ad0be
• we can detect whether it's in the viewport

Cons:

• slightly more difficult integration
• has to init an iframe to read from the AdEx Profile, but then every domain can read from the AdEx profile... this might not be so bad, since every publisher can do you a service by accessing this info; alternatively the iframe can encrypt it for the market and we can share that

related to #35

Let's add the AdEx Logo on the upper right corner of each adview - the standard for most ad networks. usually when clicking on the logo it redirects you to a page with more information about the ad - "Why am I seeing this?". This is an example from Google and one from Adshares.

Idea about the logo - if possible, we might place the animated Eddie the unicorn instead of the logo in order to capture attention

By sorting by targeting first and pricing later, we allow bidding to happen at an already targeted level: therefore you're bidding against similarly targeted ads, as it should be

If pricing is first, it means that ads can't bid against each other in their respective audiences - but only globally

automatically get targeting tags from the website context (meta tags, title) and location

example usage: new AdViewManager({ ...options, targeting: await getTargetingFromPage(document) })

due to the browser support of native lazy loading (https://css-tricks.com/native-lazy-loading/), impression events may be counted differently across browsers

related to #35

Is your feature request related to a problem? Please describe.
This is a feature suggestion with relatively low priority.

Describe the solution you'd like
Introduce "Text Display Ads" format for which users can create ads without creative - jut type ad headline, text and button copy and then start a campaign. The AdEx platform then can adopt the text to all sizes for which there is supply and matching targeting.

This is perhaps somehow related to the implementation of HTML ads.

Describe alternatives you've considered

Additional context
Here's how Google Text Display wor

ks:

the ad view manager is hosted at viewm.adex.network; we should use a cloudflare worker at this address which inserts additional global options, that include targeting with location-based tags, using the CF-IPcountry header

that way, the adview manager will be automatically targeted by location

We will use the newly added market /campaigns/with-targeting to get the country targeting

better yet, we can add automatic targeting by navigator.language, which doesn't even require a cloudflare worker: see #30

e.g. https://www.mediafuse.com/what-are-passback-tags/

We need a simple solution to embed ads in your website/app without having to include the SDK module and write any code.

The options are:

• <iframe>
  • advantage: allows for advanced targeting in the future cause of scoped localStorage
  • disadvantage: perfromance; having to fetch from the market multiple times (although, cache will help)
• insert a script AND a tag; the script would find all tags and insert ads
  • disadvantage: more complex integration
  • disadvantage: script has to watch the DOM
• self-contained HTML that includes the script and runs it
  • disadvantage: hacks

It seems that the <iframe> is the best option

So what we will do: create a small bit of HTML that includes the webpacked SDK (via script with subresource integrity) and calls getNextAdUnit() and renders it; it will take args (like targeting, etc.) from the URL parameters, which will be set in the AdEx Platform

ability to whitelist multiple tokens
depends on AmbireTech/adex-market#16, to be able to compare campaigns by value

Currently, if document.referrer is set to an empty string, the AdView just shows the ad, which is a vulnerability given that this can be overridden with the referrer policy and <meta name="referrer" content="no-referrer" />

This explains clicks that we get w/o a referrer

we should also consider how this interacts with WebViews

upon calling getAdUnits(), rather than re-request the market every time, cache the results from the market and debounce updates

using a market API (AmbireTech/adex-market#17), control the number max active channels we can earn from

this is meant to ease withdraws

it should be implemented only through changing the URL we retrieve campaigns from (e.g. /campaigns?status=... to /campaigns?byEarner=<pub address>&limitForPublisher=<pub address>&status=...)

this will be useful when the usage is high

create a keypair for the user and authenticate the event POST with that

Like this one:

For all the regular sizes: https://github.com/AdExNetwork/adex-protocol/blob/master/campaignSpec.md#spec-properties-added-to-ipfs-and-can-not-be-modified

some methods are unit testable, such as:

• getHTML
• applyTargeting
• calculateTargetScore

maybe others too

Problem

The advertiser should be able to get more context about where a lead came from

Solution

Include it in the utm_source.

Implementation wise we can add utm_source=adex_pub from the platform and then the AdView can just replace it with utm_source=adex_${hostname}

when the AdView is used in an iframe, we get one additional network request for the favicon

This is unneccessary overhead - and in advertising, low overhead and speed matter a lot

This stackoverflow thread has some nice solutions: https://stackoverflow.com/questions/1321878/how-to-prevent-favicon-ico-requests - but they're not straightforward to apply because the index.html is generated by webpack

so the fix would probably be modifying the webpack config to insert <link rel="icon" href="data:;base64,iVBORw0KGgo="> into the index.html

Implement ad slot stickiness: when a unit wins the bidding for a slot, keep returning it for that slot for the same amount of time as rateLimit.timeframe. Also, exclude the campaign from bidding while it's stuck there.

This ensures the fair value is extracted from each impression, but at the same time bidding is fair, because campaigns that have reached an eventSubmission rateLimit will not participate in the bidding for this publisher.

The cases where a campaign will often match but won't pay (higher rateLimit.timeframe than frequency cap) won't gain an advantage because of #66

This will also bring validator load down significantly.

Note: the market load stays the same: we will request the market every time to get the full ad unit object and to ensure the campaign is still in an active state. This is intentional, since the campaign may be unhealthy/unsound, in which case it's better to stop displaying it ASAP.

• targetingInputGetter
• getPricingBounds

in order for this feature to be practical, it needs #14

whitelists/blacklists for:

• advertisers (channel.creator)
• campaigns (chanenlId)
• units
• tags

Once the slots return allowedReferrers, check if our referrer matches any of them (any of the allowedReferrers is a prefix). If not, return an empty array

• research whether document.referrer is the best way to get the parent iframe url
• implement the restriction

the market can be used to save/load adslots

use that to implement dynamically loaded option overrides

we'd still take options, as per https://github.com/AdExNetwork/adex-adview-manager#options, but there should be one additional option marketAdSlot, which would allow this ad slot on the market to define option overrides for: minPerImpression, minTargetingScore, randomize, topByPrice, targeting

• refactor/rewrite so that demand will be retrieved via supermarket (/units-for-slot)
• decide whether to still allow retrieving demand via market (/campaigns) - no, cause the JS market will have /units-for-slot too
• implement new rule matching engine
• needs to collect data on what ads were shown (to apply freq capping rules by defining adView.secondsSinceCampaignImpression)
• needs to collect data what ad slots were visited the most (as part of the AdEx Profile - we will either use data to match targeting rules against it, or to hint the user into choosing their preferred categories in the Profile UI by aggregating most visited categories of sites)
• implement the Profile API

It's obviously important for advertisers that clicks are legit: therefore consider adding an intermediate page that has recaptcha/cloudflare/other anti-bot mechanisms. So on click, we'd go to that page, the page would determine if the click is legit, and only if it, it will redirect.

The event would only be counted if the page is passed successfully. The recaptcha proof can be sent with the CLICK validator event as well

a-ads uses a similar approach

slightly related to #23

create integration tests that periodically test the production version by opening a URL in puppeteer:

https://viewm.adex.network/#{%22options%22%3A{%22publisherAddr%22%3A%220xb7d3f81e857692d13e9d63b232a90f4a1793189e%22%2C%22whitelistedToken%22%3A%220x89d24A6b4CcB1B6fAA2625fE562bDD9a23260359%22%2C%22whitelistedType%22%3A%22legacy_160x600%22%2C%22randomize%22%3Atrue%2C%22targeting%22%3A[{%22tag%22%3A%22advertising%20%26%20marketing%22%2C%22score%22%3A27}]%2C%22marketURL%22%3A%22https%3A%2F%2Fmarket.adex.network%22%2C%22width%22%3A%22160%22%2C%22height%22%3A%22600%22%2C%22minPerImpression%22%3A%220%22%2C%22minTargetingScore%22%3A%220%22}}

and asserting that:

• the page loads
• the load time is under 300ms
• the publisher will get paid in no more than a minute

We will use some made up publisher addr to ensure that our particular events get recorded; since those funds won't be claimed, they will be released back to the advertiser

In case getNextAdUnit return null we can use fallbackMediaUrl and fallbackTargetUrl from AdViewManagerOptions

See https://github.com/AdExNetwork/aips/issues/10

depends on AmbireTech/adex-validator#225

Send a CLICK event to the validators, when clicked

Currently unit-level targeting takes priority
We should merge it with the campaign-level targeting: the merging logic should be designed after implementing #42 and it should be intuitive to the user

Just concatting the groups would work great, since scores would be summed. So adding some targeting to the campaign would mean it "extends" the ad unit level targeting, which is easily explainable to the user the targeting groups are effectively a logical AND so this might not be so intuitive (both campaign level and unit level need to match)

Side note: because of the way campaigns are currently stored (full spec JSON along with it), the Platform can allow users to tweak unit targeting per campaign before creating it. This gives us a lot of UX options.