Design Review 2019-11-06 16:30 UTC (amazon onetag, RTV cookie, StackDriver metrics, modal history manipulation)

[mrjoro]

Time: 2019-11-06 16:30 UTC (add to Google Calendar)
Location: Video conference via Google Meet

The AMP community holds weekly engineering design reviews. We encourage everyone in the community to participate in these design reviews.

If you are interested in bringing your design to design review, read the design review documentation and add a link to your design doc or issue by the Monday before your design review.

When attending a design review please read through the designs before the design review starts. This allows us to spend more time on discussion of the design.

We rotate our design review between times that work better for different parts of the world as described in our design review documentation, but you are welcome to attend any design review. If you cannot make any of the design reviews but have a design to discuss please let mrjoro@ know on Slack and we will find a time that works for you.

[mrjoro]

The Access & Subscriptions Working Group will be presenting their periodic updates at this Design Review (10-15 minutes). This update is moved to the next design review.

/cc @ampproject/wg-access-subscriptions @jpettitt

[mrjoro]

@vigneshcamar will discuss #23166 (amp-amazon-onetag).

/cc @lannka

[jpettitt]

I'm going to be traveling on the 6th can we swap the Access & Subscriptions WG report to the 2019-11-13 design review?

[danielrozenberg]

I'd like to discuss #25205, an intent to implement a new opt-in mode (cookie) to get served AMP runtime/extension versions by specifying an RTV numbers in experiments.html

[jridgewell]

I'd like to bring up the AMP CSI metrics system again: #25228

[cathyxz]

I'd like to briefly discuss history manipulation in modal components: #25080.

[jpettitt]

@mrjoro did you see the request to swap dates for the wg report.

[mrjoro]

yes, I think that's fine; I'll update the issues

[honeybadgerdontcare]

@sebastianbenz looks like we needed to make a comment and not just reference the design review. so we should do that for the next design review we can attend #25026

[mrjoro]

sorry about that @honeybadgerdontcare and @sebastianbenz!

[mrjoro]

Amazon onetag

• is this similar to skimlinks? yes
• does this only affect amazon links? yes
• why not generic solution (amp-link-rewriter)?
    - have special requirements; see Flow section in design doc
    - e.g. append tagValues (from backend database) only if the feature is enabled; fetched from backend service
    - proposal to add a call to a remote server to render the page, but they have a very special flow (Content Performance feature in Flow of design); can we combine these calls?
      - trying to keep this similar to how the current JS works for this feature, which makes two calls
    - seems like all of this stuff would be straightforward to add to the link-rewriter component
    - there's a similar pattern in amp-analytics; fetches config remotely, then if the configrewriter is configured, will visit the endpoint again; flexible to meet the analytics requirement
    - making this generic allows for this feature in other link rewriters, which could be important for opt-in/opt-out requirements
• pixel analtyics
• work with @lannka on adding requirements to amp-link-rewriter

[mrjoro]

RTV

• what is the list of RTVs shown in the drop-down? we can make it arbitrarily long (last two weeks, infinite); should match with the retention plan we're working on
    - there are on/off cookies for canary & RC; let this cookie work with the 13 digits?  experiments are harder
• how can we ensure users don't get stuck on the RTV forever?  cookie that expires fast (1 hour); it's only for debugging purposes
    - sometimes it takes half a day to repro a bug, 1 hour may cause issues; 12 hours would cover a full work day
• what if there is a security issue in a build?  should we remove it?  this is addressed in the I2I
    - we should also stop serving the RTV with the security issue; @danielrozenberg will file an issue to track this (this isn't related to this issue)
• how does this interact with a site sticking to a specific version?  since this is cookie-based the website owner can't force you to do it; this supports the user case, not the publisher case; publishers today can use a version-locked RTV URL, but then it's not valid; there is a plan to have "monthly releases" that's different
• is there any easier way to implement this?  chrome extension?  those aren't generic enough

[mrjoro]

CSI metrics

• switching CSI collection from Google SRP to StackDriver; current system has 3 days of latency, with only 8 days of retention
• is there an out-of-the-box solution like Sawmill so we don't have to build a FE?  we want to move away from Google infrastructure?  but isn't this an issue with StackDriver?  we own the GCP service, we can give access to anyone who should have it, not just Google employees
• does it support cache usage?  we can only do this through the viewer integration script, we could slowly allow origin pages to opt into metrics collection
• can caches other than the Google AMP Cache use a different endpoint?  All of the URLs that we push data to including error reports are configured through the urls.config.js file (or whatever it is); other AMP caches could modify the config value to support whatever endpoint they want
• StackDriver monitoring is not really designed for frontend instrumentation; they specialize in server implementation; we have to build a system in front of it to do things correctly; @jridgewell spoke with monitoring team and they're okay with this approach, but they don't have an existing product that meets this need
• logging and monitoring are two separate services in GCP; you can push whatever log data you want and it'll work; in order to push from a server to do monitoring you have to do batching
• do not track?  possibly an attribute in the doc; data is anonymized, no client identifier, IP is turned into a country code
• how long does it take between metrics from the client to being able to view anonymized version?  minutes
• we should be able to group data by RTV / experiments?  yes; can add any labels we want
• have we looked at other vendors to fit the use case?  no since there's more overhead for now and there's an urgent need; long term we can look at switching
• is there a transition period where we're reporting to both so we can compare data?  sure

[mrjoro]

history manipulation of modal components

• main question: what do users expect when the back button is hit?  (sidebar is one example, but there are others like gallery lightbox); could treat them all the same or treat them differently
    - expectation changes by platform (iOS, Android, desktop)
    - Android looks a lot less broken today when you swipe (doesn't show the overlay)
• have we discussed this with UX?  they're taking a look at it
• iOS UI guidelines don't have sidebar; they use an overlay with a "close" or "cancel" button on the bottom
• will merge disabling history manipulation to fix this bug, and bring the bigger question to UX