Step 1 of 13. Google Cloud Console, project selection screen, browser open via the MCP chrome extension. Three architecture decisions had been agreed before this session: throwaway GCP project per reader, OAuth desktop flow over service accounts, Steps components over prose. The first screenshot was ready to capture.
Then I navigated to the OAuth consent screen configuration, and the path had changed. Google had moved it under a new label, “Google Auth Platform”, and the steps I had prepared no longer matched what the console showed.
Improving on the earlier piece, which documented why those three calls were made before the build started, this is what they looked like at runtime.
What the three decisions were
Chapter 2 of the GSC + GA4 automation guide is the Google Cloud setup chapter. The rest of the course is Python and CLI. Chapter 2 is entirely UI-driven: create a project, enable the Search Console and Analytics Data APIs, configure OAuth credentials, download the JSON file. Every architectural choice for the chapter is visible in the screenshots.
Three decisions were settled before the first screenshot:
- Throwaway GCP project per reader. The walkthrough asks readers to create a new project. Nothing touches an existing project or existing credentials. Readers can delete the project afterward. Self-contained by design.
- OAuth desktop flow over service accounts. Service accounts require project-level IAM access. Readers in a learning context won’t have it set up; making them configure IAM first turns a programming guide into an IAM tutorial. OAuth desktop flow avoids that. It needs only what the chapter itself creates: app credentials downloaded as a JSON file, token exchange in the Python CLI.
- Steps components over prose. The site has a
<Steps>and<Step>component pair for procedural UI walkthroughs: numbered steps with an inline screenshot per step. The alternative, paragraphs with screenshots scattered nearby, is illegible for anything beyond four steps. Chapter 2 has thirteen.
The earlier article covers the reasoning. This one covers the execution.
Thirteen steps
Thirteen is not a number I set in advance. It came out of the workflow: every step with a distinct UI state, a decision point, or a confirmation worth seeing gets a screenshot. Project creation. API enablement for Search Console and then Analytics Data. OAuth configuration. Credentials download. That sequence totals thirteen.
Capture workflow: MCP chrome extension for browser visibility, step through each screen, confirm the framing, advance. One sitting.
The Steps component gave each of the thirteen a clean container. Each <Step> holds the instruction and the screenshot inline. The reader sees the directive and its visual confirmation together. No scanning between a paragraph and a figure two scrolls away, no uncertainty about whether a screenshot applies to the current step or the previous one.
That’s the practical return on the third decision. The structure is load-bearing. Remove the Steps component and replace it with prose, and a thirteen-step UI walkthrough becomes difficult to follow. The decision wasn’t about appearance.
The OAuth rewrite
The throwaway-project decision ran without friction. The Steps decision ran without friction. The OAuth decision held, but the interface it applied to had changed.
Google Auth Platform is where OAuth consent screen configuration now lives inside a GCP project. New label, new navigation path, shifted terminology. The steps I had prepared and the screenshots I was about to capture no longer matched what the console showed.
The OAuth section was rewritten for the new UI: new step descriptions, new screenshots, same architectural decision underneath. Desktop flow, not service accounts.
What survived the rewrite is the reason the decision was made. Readers following a learning guide won’t have IAM project access unless the guide itself sets it up. Service accounts require that access; the OAuth desktop flow doesn’t. Google can rename and reorganise the OAuth configuration screens. The decision stays correct regardless.
That distinction is worth making explicit: architectural decisions sit above the interface; documentation sits at the interface level. The OAuth rewrite was a documentation rewrite. The architecture didn’t need revisiting.
The standing cost of a screenshot-driven chapter is that it tracks the interface, and interfaces change. Prose-only chapters age slowly. A UI walkthrough tied to console layouts decays much faster, because the layout itself is what gets photographed and embedded into the page. The OAuth rewrite was the first instance of that cost in this course. The Search Console and Analytics console interfaces are also capable of a redesign.
Out of scope: proactive monitoring for Google console UI changes. The rewrite was reactive. If the guide reaches a maintenance level where monitoring is worth building, that’s a separate decision.
The link regression
Caught from a rendered screenshot, not a source review.
Chapter 1 has a “What the next chapters cover” list. In a rendered view, chapters 2 through 4 appeared as links and chapters 5 through 8 appeared as plain text. The colour difference is visible immediately in rendered output; it is easy to miss reading MDX source.
The cause: chapter 1 was drafted when chapters 2 through 4 were the only planned chapters. Chapters 5 through 8 were added later, and the list wasn’t updated.
A pass across all eight chapters converted every plain-text chapter reference to an inline link. Mechanical fix once found. Finding it required a rendered view, which the screenshot workflow produces as a side-effect of working through each step. The inconsistency surfaced because of that, not despite it.
8 of 8
The full course shipped: all eight chapters live.
Chapter 1 is the motivation chapter. Chapter 2 is the GCP setup walkthrough. Chapter 5 covers the Python CLI shape for Google APIs and runs to around 1700 words. The remaining chapters carry the reader through authentication, data extraction, and the full automation pipeline.
The three decisions held. The OAuth section rewrite was the only execution-time reversal, and it was a documentation change rather than an architectural one. The decision stayed; the screenshots changed. A reader following chapter 2 today creates a fresh GCP project, moves through thirteen numbered steps with a screenshot at each, and ends with a credentials JSON ready for the next chapter.
The course is at /learning/gsc-ga4-automation.
