jonasz
commented
4 years ago Hi Alex,
I think the use case of
Recommending products to the user based on the products that the user has already seen
is already covered by the proposal. The advertiser should be able to add a user to an interest group, and supply product_ids chosen based on products seen by the user (even if it's just a single product).
Recommending products that were added to the advertiser's catalog after the user's visit to the advertiser's site sounds like a great use case that is not explicitly supported now, I think it would be great to add.
It seems the exact design would rely heavily on the amount of flexibility we have during creative rendering: https://github.com/jonasz/product_level_turtledove#creative-construction
It would be great to strive for as much flexibility as possible to pick the products during rendering. I think to push this idea further, this has to be consulted and discussed in more detail with the browser teams.
Thanks for the suggestion!
Let’s consider the use case of recommending new products to a user who has not visited advertiser’s website for some time. For example, a user may have searched for hotels on travel website weeks ago. The availability and pricing may have changed since then, and these changes are not reflected in the set of products stored in the browser.
Recommending products to the user based on the products that the user has already seen is another important use case that would be easier to support with the below modification
Having enough products in the browser to fill a multi-slot ad is another such use case. If a user has viewed only one product on advertiser’s website, it may still be valuable to show additional products in an ad, even though the user has not viewed those products.
These use cases would be easier to support with the proposed suggestion.
When returning product data, a server can return data for multiple products. These multiple products will be recognized as separate products by the browser.
More specifically, the browser will send to the server for each interest group the following information (note that the format is non-essential and is included only for the ease of elaboration): { ‘interest_group’: ‘interest_group_id’ ‘product_ids’: [ ‘product_id.1’, ‘product_id.2’, … ‘product_id.k’ ], }
assuming that k products are associated with the interest group. Note that no assumption here should be made that the browser is sending all of the product ids registered with the browser by the advertiser. The browser may choose to send ids one by one, and may choose only those ids that pass privacy requirements, such as the minimum number of users who also saw a specific product.
There are two approaches as to what the server might send back. In approach one, the server will send back a list of products data for each product key. In this approach, a product key is meant to be a seed, and the server will send back the list of products corresponding to that seed that is meant to fill an ad. The JS written by DSP can then decide which list to use for filling the ad. (Note that the format is non-essential and is included only for the ease of elaboration)
productDataListKeyed = {[ [‘product_key’: ‘product_id.1’, ‘products_data’: [product_data.1.1, product_data.1.2, ..., product_data.1.n1]], [‘product_key’: ‘product_id.2’, ‘products_data’: [product_data.2.1, product_data.2.2, ..., product_data.2.n2]], … [‘product_key’: ‘product_id.m’, ‘product_data’: [product_data.m.1, ..., product_data.m.nm]] ]}
where m can be strictly less than k.
The purpose of product_data.x.y is to provide information that would help to determine products to render, as well as to provide information needed for the product’s rendering (rendering data). As an example, product_data.x.y can contain information about categories that the product is part of, as well as rendering data or an internal product id needed to request rendering data from a server.
Then, in rendering the browser will give productDataList to the rendering code, and the rendering code can decide which of the sublists in productDataList to use in rendering. Since productDataList is ordered, the code could attempt to use the initial element first. That is, the sublists within productDataListKeyed could be ordered by the predicted value. The idea here is to preserve the relationship between a remarketing product id and the sublist generated with that remarketing product id as the seed. This is done so that if the rendering code decides to render, say product_id.2, then it can select the other products to fill the ad from the product_id.2’s sublist.
In the second approach, the server will send the list of products data related to all the keys:
productDataList = [product_data.1, …, product_data.M]. In this approach the JS written by DSP can choose which of the items in the list to use in filling the ad. The products can be ordered by their expected value, so that the browser can simply choose the initial segment of the list in filling the ad.
The second approach is more efficient, in that unlike in the first approach, the product data does not need to be repeated. On the other hand the first approach makes it simpler for the browser to fill an ad by simply choosing one of the sublists, rather than choosing items to fill the ad from a single large list. Choosing a sublist may be motivated by the fact that on some publisher pages certain products cannot be shown, or showing certain products is preferable to other products. In that case DSP’s JS can choose the appropriate product and the corresponding sublist. For instance, a publisher may choose to exclude certain categories of products. To implement such an exclusion, product_data stored in the browser can contain product’s classification information, which will be used to determine whether showing the product is allowed on the publisher’s site.
Disclaimer. Teams from across Google, including Ads teams, are actively engaged in industry dialog about new technologies that can ensure a healthy ecosystem and preserve core business models. Online discussions (e.g on GitHub) of technology proposals should not be interpreted as commitments about Google ads products.