Plan 487: the GA4 listing tag in the bars

Plan 487: the GA4 listing tag in the bars

market-nana reports the boss tagged Sizecurve's listing with GA4 on 10-19 (a colleague's word; ask the boss). Shopify's "Track your listing traffic" doc confirms view_item, add_to_cart and the surface_type / surface_detail parameters. Add a search-views bar for Close of Day and Flatdesk, measured against Sizecurve's 10-20 to 11-02 count. Add "GA4 tag" to both approval-day lists. Ask the boss whether I can read the property.

---

Plan 488: three text fixes in Flatdesk while it is in review

In the take, a new ticket's Tags box showed the placeholder "refund, shipping", which reads as tags the app set itself. A reviewer could think so too. One agent will:

• change that placeholder to "Add tags, separated by commas";
• make the import address placeholder neutral;
• delete the stale VERIFY comment in themeEditorLinks().

Text only, no network. The deploy waits for the boss's yes.

---

Plan 489: changelog sweep update, 10-02 to 10-20

The 10-02 sweep found the door that became Close of Day. One agent will repeat its method on the merchant and developer changelog entries since then:

• class each entry;
• for each new door with a pain named: two App Store searches and one Community thread;
• list any native feature that overlaps Sizecurve, Close of Day or Flatdesk.

The notes go in scratch/changelog-sweep-2026-10c-notes.md. Nothing is built from this without a case and the boss's yes.

---

Plan 490: where our listings sit in App Store search

A search view needs the listing to be seen. One agent will read App Store search for each listing's search terms, plus four extra terms. It records:

• Sizecurve's position for each term;
• the shelf Close of Day and Flatdesk will land on: ads, review counts, how many cards are free to start.

This is the day-0 baseline for reading the GA4 search views.

---

Plan 492: two X posts on the month-later rescan

Engaged views have come mostly on launch days, from zoo and X. LinkedIn reaches about 25 people a post and has sent no visit. X has sent 25 visits so far, and its last posts went out around 10-15. One agent will write posts 15 and 16 on the rescan and schedule them on the X channel for 10-21 and 10-22 at 15:00Z. Figures come from the page, and the figure gate stays as it is.

---

Plan 494 — dev.to follow-up on the rescan (draft only)

One agent drafts a dev.to follow-up to the 09-30 article: how the same 298 catalogues were read again a month later, matched by handle and colourway with no ids, and the result with its caveats. Links the study page #a-month-later, which Google has not yet found. Nothing is published without the boss's yes.

---

Plan 496 — better search terms for Sizecurve

Three of the five live search terms leave Sizecurve off page 1 (apparel inventory #36, demand planning #72, inventory forecast not in 72). One agent reads where Sizecurve sits, logged out, on 14 truthful candidate terms (restock, low stock, clothing inventory and so on) and writes scratch/search-candidates-2026-10-20.md. Then I pick a set, weigh it against the GA4 search words once those arrive, and ask the boss to enter it.

---

Plan 497 — where the first listing view came from

Read the kill count, and check which of our links to the listing carry a utm_source, so that a GA4 view_item with none can be traced to a channel.

---

Plan 498 — evidence for a listing-analytics app (the boss's prompt)

The boss asked: "What about an app that solves the tracking analytics problem". I read it as the problem we hit this week: a Shopify app developer cannot easily see how merchants find their listing (search words, surfaces, rank per term). One agent gathers evidence for two shapes, A (a ready report from the listing's GA4 events) and B (keyword rank tracking), into scratch/applisting-notes.md: demand with links, shelf, market size, route (GA4 Data API scope verification, App Store read terms, Partner API) and reach. Then I write scratch/applisting-case.md with a verdict. No build without a passing case and the boss's yes.

Widened the same night: the boss said "Well it doesn't just have to be for Shopify". The agent's scope now adds other developer marketplaces (CMS plugins, browser extensions, work-tool and editor marketplaces, other commerce platforms): what analytics each gives developers today, tools for it, developer asks, listing counts. Mobile app stores get one paragraph, since that tool category is already large and mature.

Phase 487: the GA4 listing tag in the bars

• Read Shopify's "Track your listing traffic" doc. The listing's Tracking information takes a GA4 ID. The App Store then sends: - view_item when the listing opens; - add_to_cart on Install; - with an API secret, the server-side shopify_app_install and shopify_app_ad_click. - The listing URL carries surface_type (home, search, search_ad, category, collection, story, partners, app_details, app_group) and surface_detail, which is the search words on search. - The doc doesn't say whether saving the field triggers review.
• market-nana says the boss added the tag to Sizecurve's listing on 10-19 with no review notice. Not yet confirmed by the boss, so not in FACTS.md.
• The bars from Phase 486 gain a second line for Close of Day and Flatdesk. Their search views (view_item, surface_type=search) in the first 14 days must be at least Sizecurve's from 10-20 to 11-02. This tells "not found" apart from "found but passed over" when installs are 0.
• Approval-day lists, both apps: ask the boss to add the GA4 tag to the listing.
• The reply went to market-nana in thread shelf-method-bars. Both mails were moved to mail/read/.

---

Phase 488: three text fixes in Flatdesk

• I read the diff myself: - the Tags box placeholder "refund, shipping" became "Add tags, separated by commas"; - the import address placeholder became "https://your-help-desk-address"; - the stale two-line VERIFY comment in themeEditorLinks() is gone.
• No code changed.
• Checks: tests 291 of 291 before and after (no test pinned the old text); key check clean; hex and myshopify grep on the diff returned 0.
• Since Deploy 10, a Worker deploy would ship only these lines.
• Left for later: - src/legacy.mjs:58 still gives the old example address in an error message; - the rules and articles forms show sample values ("Wholesale enquiries", "Returns and refunds"). Those sit on forms for new items, so they read as examples.
• Not deployed. Asked the boss.

---

Phase 489: changelog sweep update, 10-02 to 10-20

• One agent read 15 merchant and 17 developer entries in the window. Neither feed has anything after 10-16.
• Doors found: none worth a case. - The only developer "opens" names no merchant pain. - The developer feed now also carries 12 entries dated 07-01 to 10-01 that the 10-02 notes lack. Three of them are doors with a pain, and all three were dropped: - buyer-requested order edits: owned shelf; - Purchase Order Read API: owned shelf, still filling; - Collection Sources: native.
• Touches our apps: - Sizecurve: merchant entry 10-06, "Analyze purchase orders in Shopify Analytics", adds "Purchases on order", for open purchase orders without linked transfers. If such units aren't in the inventory incoming quantity, Sizecurve overstates what to buy for a store using Shopify's purchase orders. Not confirmed. To check before any Sizecurve work after the verdict. - Flatdesk: buyers can now request removal of unfulfilled line items, and apps may resolve or decline. That's a candidate feature for after approval. - Close of Day: nothing.
• 81 requests, all 200. Notes: scratch/changelog-sweep-2026-10c-notes.md. I scanned it for hex, mail addresses and named services: clean.

---

Purchase orders and Sizecurve's On order column (read only)

• Sizecurve's On order column is Shopify's incoming quantity (src/shopify-data.mjs:116-128). The dashboard's tooltip says it comes "from a purchase order or transfer".
• Shopify's docs, read today: - incoming is stock "on its way … for example … in an incoming shipment"; - a transfer can be created for a purchase order only after it's marked Ordered; - the 10-06 "Purchases on order" report exists for "open, ordered purchase orders that don't have linked transfers". - None of them says when purchase-order units become incoming.
• Likely: units on an Ordered purchase order with no transfer are not incoming. If so, Sizecurve tells such a store to order them again. Not confirmed.
• If the 10-27 verdict is PASS, test it on the dev store before p429: create a purchase order, mark it Ordered, read incoming, then add a transfer and read again. On KILL, it's moot.

---

Deploy 13: Flatdesk's Phase 488 live

• The boss: "Deploy."
• npm test 291/291, then deployed. Live inbox.js has both new placeholders (grep count 2).
• The boss on the GA4 tag and access: "yes, but it will take a day or so to work". Recorded in FACTS.md and LEARNED.md.

---

Phase 490: where our listings sit in App Store search, 10-20

One agent read 33 search pages, logged out, all 200. File: scratch/search-positions-2026-10-20.md (no app named except ours; scanned clean).

Sizecurve's organic position. The live terms are the 09-30 set (FACTS 09-30); the 10-04 set was never entered.

Term	Position
size curve	#3
size run	#7
apparel inventory	#36
demand planning	#72
inventory forecast	not in first 72
sizecurve	#1
purchase orders, reorder, inventory management (10-04 set only)	not in first 72

What I take from it:

• Sizecurve is near the top only for words it chose itself. In the 10-04 read, the App Store's search box did not suggest "size run" or "size curve", and it only suggests what merchants type. For the words merchants do type, Sizecurve isn't in the first three pages.
• That fits 0 installs from search. The GA4 tag will show it in numbers from about 10-21. Don't change the search terms before that reading: they're the boss's field, and the bar compares against this baseline.
• Free to start is the norm on every shelf: 22 to 24 of the first 24 cards on every term. Sizecurve's card says "Free trial available". This supports scratch/sizecurve-free-case.md.
• Close of Day's shelves (page-1 median reviews / cards under 50, of 24): - finance 13 / 18; - end of day report 35.5 / 13; - pos 57 / 9; - cash drawer 66.5 / 11; - sales tax 117 / 7; - reports 269.5 / 7.
• Flatdesk's shelves: - shared inbox 7 / 16; - help desk 29.5 / 15; - live chat 119.5 / 8; - helpdesk 140 / 10; - customer service 153 / 7; - ticketing 187 / 9.
• Ads can't be seen in a logged-out read. Sizecurve's own running ad never appeared. Ad positions come only from the ad dashboard.

---

The 14-day bars, third version

• Phase 490 shows Sizecurve isn't seen for the words merchants type. So its 10-20 to 11-02 search views will likely be near zero, and "at least Sizecurve's" would pass by default.
• The bars for Close of Day and Flatdesk are now: 1. installs, as in Phase 486; 2. on day 14, read logged out, the listing is on page 1 (top 24) for at least 2 of its 5 search terms; 3. at least 10 GA4 search views in 14 days. That's my own number, set before launch.
• Sent to market-nana, the last message my side has in thread shelf-method-bars.
• 15:07Z: kill count 48 of 50, unchanged. The 13:30Z profile post and the 15:00Z Page post have gone out; no linkedin source yet on 10-20.

---

Google search, 17:10Z

• Search Console, 09-20 to 10-20 with fresh days: 6 pages with impressions (/ 9, /dataset 8, /privacy 5, /terms 4, /check 3, /split 3) and 0 clicks.
• /broken-size-runs: "URL is unknown to Google". The sitemap lists it, and Google last downloaded the sitemap on 10-17 (13 submitted, 0 shown as indexed).
• This is the crawl-priority finding of 10-14: / links to the page, and Google hasn't followed the link. A sitemap resubmit wouldn't change it, so none was made. Only a link from a page Google already trusts would. A trade article from market-nana's pitch would be one.

---

Phase 491: LinkedIn numbers, read 19:10Z

One agent read Buffer and /api/views (3 requests, nothing changed).

Post	Sent (UTC)	Impressions	Reach	Reactions
Page post 1	10-17 15:00	56	41	0
Profile post	10-19 13:30	34	25	1
Page post 2 (links /check)	10-19 15:01	1	1	0
Profile post	10-20 13:30	not yet updated
Page post 3	10-20 15:01	not yet updated

• Buffer returns no clicks. No linkedin source on any day.
• On 10-19 and 10-20, /broken-size-runs had 3 hits a day and 0 engaged views.
• Kill line: 48 of 50, needs 2 by 10-27.
• Reading: the Page reaches next to no one, and the profile reaches about 25 people a post. LinkedIn alone is unlikely to bring 2 engaged views this week. Read today's two posts again on 10-21.

---

Phase 492: two X posts on the rescan, queued

• Posts 15 and 16 are in marketing/X.md, with x15 and x16 added to X_DUE. Both are scheduled on X, for 10-21 and 10-22 at 15:00Z. Read back: twitter, scheduled, text equal to X.md. - 15: the picture (middle sizes gone in September, the same ends on the shelf a month later), "two in three", and the no-prices caveat. - 16: "clearance would clear it". Of 1,279 comparable runs, 52 sold out, 178 had the core back in stock and 864 were still stranded. Each figure is a row on the page.
• Both pass the figure gate. The agent checked that the gate still refuses wrong figures: it fed in 1,278, 53, 179 and 865, and all four were refused.
• schedule.py x15 stops with a KeyError because x15 and x16 aren't in PAGES. The brief allowed only X_DUE, so the agent sent them through schedule.py's own check and send functions. Left over: add both to PAGES, so the plain command and test_figures.py posts cover them.
• Tests 681 of 681; key check clean; 12 requests, all 200.

---

Phase 493: X retired, posts 15 and 16 deleted

• The boss: "X posts are retired". Recorded in FACTS.md.
• One agent deleted exactly those two scheduled posts (Buffer answered DeletePostSuccess twice). Read-back: 0 scheduled on X, and 0 in the whole queue. 5 requests.
• X.md's notes now say both were deleted unsent and must not be scheduled.

---

Phase 494 — dev.to follow-up drafted

• Draft: scratch/sizecurve-devto-rescan.md, "I read the same 298 Shopify catalogues again a month later", 986 words plus the classify() excerpt, published: false. Agent made 2 GETs (both 200), no dev.to API call.
• Checked every figure against scan/persistence-2026-10.txt lines 4-45 and the live page: all match. No store names, no hex, no addresses.
• Found: the page says the second unread store "could not be reached"; the txt says "not fetched yet". The draft says only "one was not read". Page wording to fix at the next Sizecurve deploy.
• Next: ask the boss whether I may publish it or they want to post it.

---

Phase 495 — dev.to rescan article published

• The boss: "Post it". One agent posted scratch/sizecurve-devto-rescan.md (above its publishing notes, published: true) through the DEV API: 201, live 2026-10-20 23:17Z at https://dev.to/bananafestdestiny/i-read-the-same-298-shopify-catalogues-again-a-month-later-15j4
• Read back by id: body equals what was sent. Public page 200 and carries both links (broken-size-runs#a-month-later, the 09-30 article). 4 requests, no retry, no other article touched.
• Next: on 10-21, read its views and reactions, and any dev.to referrer on the study page in /api/views.

---

Phase 496 — candidate search terms read

• One agent read apps.shopify.com/search logged out for 14 candidate terms (40 requests, all 200, 01:09–01:11Z 10-21). Write-up: scratch/search-candidates-2026-10-20.md.
• Sizecurve is on page 1 for one: broken size #7 (2,281 matched, page-1 median 34 reviews). Not in the first 72 for the other 13, including the truthful restock, restock planning, inventory planning, stock forecast, replenishment.
• Taken: with 0 reviews, Sizecurve ranks only on words its own text owns (size curve, size run, broken size). Generic inventory terms are held by apps with hundreds of reviews. New terms can only move a slot from nothing to a niche term.
• Candidate swap: inventory forecast (not in 72) for broken size (#7). Waiting on two things: the boss on whether a search-term edit re-triggers review, and the GA4 search words (from about 10-21) to see whether anyone types it.

---

Phase 497 — kill count and the untagged listing view

• Kill read (01:40Z 10-21): engaged 48 of 50, checks 11 of 10, 2 remaining, window open to 10-27. 10-20: 17 arrivals, 4 rendered, 0 engaged. Last engaged view still 10-17.
• GA4 so far: one view_item, on a phone, not the boss (FACTS), at apps.shopify.com/sizecurve with no utm_source and no surface_type.
• Our listing links: the site (10 links, utm_source=sizecurve-site), the email (sizecurve-email), the dev.to articles (devto) and LinkedIn (linkedin) are all tagged. The only untagged ones are the short-video captions in marketing/schedule.py ("type apps.shopify.com/sizecurve"), which ask the viewer to type the address, plus App Store pages that were not reached by search. So the first view was typed or bookmarked, not one of our tagged links: possibly a video viewer, unproven.
• Searched past cases for a next app: all 13 in scratch/*-case.md are dropped, parked or live. scratch/shelf-suggest-2026-10.md (10-04) already showed Sizecurve's words are not typed in App Store search; on 10-04 "size" suggested only size chart and size guide; whether "broken" suggests broken size was not tested. The term swap stays low value until GA4 shows a search word.

---

Phase 498 — listing-analytics case: fails

• Evidence: scratch/applisting-notes.md (one agent, 189 requests). Case: scratch/applisting-case.md. Verdict: fails, dropped.
• Shopify: 17 developer asks, but about 20 tools already serve them, 7 doing both report and rank at $19-$49/mo with free tiers. Other marketplaces: 7 thin asks across 14; several already give developers search words or funnels.
• Route: apps.shopify.com/robots.txt has Disallow: *q=* for all agents (I re-read it), so rank tracking is out. That also means our own Phase 490 and 496 reads and the 10-04 suggestion sweep broke it. Stopped: no more App Store search or autocomplete reads, tools/rank.mjs not to be run. Recorded in LEARNED and memory.