The Subscription & SKU Migration
Jan - Apr 2026

Elliot Mitchell engaged as Skio account manager; tracker started with Nikita

Elliot, the dedicated Skio account manager, had been working with Nick (Nikita) since ~November 2025 and already maintained a tracker (a shared Google Sheet, id 129ynNugoYBUA8kijItKP7vqXPNa-YMT7yrTUucx1lAw) of Nuora subscription fixes. The tracker contained rows covering shipping interval alignment (Row 2), variant restructure (Row 3), cancel flow (Row 8), splash screen (Row 9), cancel-flow conditions for orders <3 and >3 (Row 15), and payment recovery (Rows 16-17). Hardik was later added to the Skio-Nuora Slack channel by Nikita.

• Skio tracker maintained (Google Sheet id 129ynNugoYBUA8kijItKP7vqXPNa-YMT7yrTUucx1lAw)
• Hardik added to Skio-Nuora Slack channel

Payment-recovery context: 32% Nov recovery rate, 1,787 subs lost to failed payments

Standalone Slack-history facts (separate from the Nov engagement): payment recovery ran at a 32% recovery rate in November, and Nuora lost 1,787 subscribers to failed payments in one month. Context for the dunning/payment-recovery tracker items (Rows 16-17).

Cancel Flow PDF shared in Slack thread; Elliot's Loom videos shared

A Cancel Flow PDF was shared in a Slack thread on ~Nov 27 (referenced as a meeting resource; year not stated in source). Authorship of the PDF is not attributed. Elliot also produced Loom videos on Product Setup and Dunnings Optimization, shared in Slack ('Elliot's Loom').

• Cancel Flow PDF shared in Slack thread
• Elliot's Loom videos: Product Setup, Dunnings Optimization

December $0 billing disaster - bulk 3-pack to 1-pack change without removing the discount

Nick ran bulk operations to change 3-pack subscriptions to 1-pack at $58.99 but did not remove the $92.88 discount. The discount remaining on the lower-value order produced hundreds of free orders ($0 billing). Described as the December $0 billing disaster; feeds the priority of fixing subscriptions with discount greater than order value.

• bulk operation: change 3-pack to 1-pack at $58.99 (discount not removed)

December bulk operation cleanup referenced as open audit item

In the call agenda's Current State Audit, Hardik lists 'What's the status of the December bulk operation cleanup?' as an open question for Elliot (December year not stated; only 'the December bulk operation cleanup' named). The source only queries its status. He also asks whether subscriptions are still tied to deleted product variants and how many subscriptions currently have discount value greater than order value.

• December bulk operation cleanup (status unknown / to be audited)

Nuora Deodorant PDP project context created (new SKU line)

The Deodorant SKU/Context.md file (session notes dated Jan 25, 2026) documents a new Nuora Deodorant SKU line being built as a PDP. Three SKUs/variants: Roll-On Deodorant ($39.99, was $54.95) for underarms; Liquid Cream Deodorant ($39.99, was $54.95) for intimate areas; and a DUO KIT bundling both ($39.99, was $79.98, Save $40, marked Best Value). Copy is client-provided and must not be modified. This is product/SKU structure, not a Skio subscription billing change.

Skio support call with Atul Amresh: walkthrough of Bulk Operations / Swap Product Variants to consolidate Nuora gummies variants into hero product

Hardik had a 64-minute Skio support call with Atul Amresh (atul@skio.com) to learn how to consolidate subscriptions from multiple product variants into a single hero product. The goal: migrate subscriptions off three test variants of a product (Feminine Balance gummies BOGO) onto the ~$4M hero product and simplify product management. Hardik wanted to learn the process self-service. Atul noted the merchant has a dedicated MSM (account manager) in Skio and offered to loop them in. Hardik also disclosed the brand belongs to 'some other person from Switzerland' who gave him Shopify access and pays him as a solo contractor.

"The reason I wanted to learn this was because I don't have to, you know, go back and forth again."Hardik

"This is our hero SKU, this is the hero product, which has four million dollars in sale."Hardik

"this is not my brand this is brand of some other person from Switzerland and he has basically given me access to his Shopify"Hardik

No prepaid selling plans confirmed; all subscriptions are standard subscription

Early in the call Atul checked whether the merchant uses prepaid subscriptions and confirmed they do NOT have a prepaid selling plan - all are standard subscriptions. Simplifies billing-interval reasoning since there is no prepaid layer.

• Checked selling plans for prepaid - none found; confirmed standard subscription only

Created dynamic segment to preview affected subscription volume before bulk operation

Atul walked Hardik through creating a dynamic segment under Features > Segment in Skio to preview how many subscriptions would be affected before running any bulk operation, using a Product Based 'contains product' condition. Single variant preview showed 2 subscriptions; all three variants with an OR condition showed 15. Atul advised always creating the segment first (preview model fails at high volume like 100-500 subs) and exporting a CSV containing subscription IDs and customer emails. The segment is a record-only bulk operation that performs no action.

• Created dynamic segment (Product Based 'contains product' condition) in Skio
• Exported segment CSV (subscription IDs + customer emails)

Difficulty finding Skio variant ID due to identical SKUs and identical product titles

Hardik and Atul struggled to identify the correct Skio variant ID for the hero product because all variants share identical SKUs and the same naming convention across many products. Atul explained bulk operations in the self-serve UI require the Skio product variant ID (not the Shopify variant ID), while Skio's internal backend tool can accept the Shopify variant ID. The old/new product could be searched by title in the Bulk Operations page. Atul recommended adding a variant identifier to product titles going forward.

• Located Skio variant ID by opening variants and using Ctrl+F
• Searched old/new products by title in Bulk Operations

"to perform the action in SKU, you need to use SKU product variant ID"Atul Amresh

"maybe next time you can add an identifier to the product title that, so that not all the product titles are same"Atul Amresh

Discussed Kaching Bundles discount mechanism and incompatibility with subscriptions; Skio Bundle suggested

Hardik and Atul discussed the discounts auto-applied on the gummies PDP (Hardik's highest-converting PDP). The discount applies automatically on add-to-cart and is not a proper discount code; the team recently switched to percentage discounts (previously fixed-number). Atul concluded these are product-level (not order-level/certified) discounts, so bulk operations cannot easily identify or remove them, and that bundle apps generally are not compatible with Shopify subscription apps or the Shopify subscription API. Hardik explained Kaching's primary value is HTML/CSS/JS-level offer tweaking on PDP pages. Atul suggested Skio's own Bundle feature (no extra fee) could replace Kaching if it solves the same use case. They agreed to keep the old price with the same discounts for the swap and revisit discount removal later.

"bundle itself is not compatible with any subscription app on Shopify or the Shopify subscription API"Atul Amresh

"Kaching bundles basically what it helps us do is... we are able to do tweaking on the HTML, CSS, JavaScript level on the PDP pages"Hardik

"if possible, you can use Skio bundle as well, it is in the app. There is no extra fees for that"Atul Amresh

Pricing decision: keep old price with same discounts to avoid customer churn

Hardik initially considered new-variant pricing with all discounts removed, but after Atul explained charging a higher price without prior communication would upset customers, Hardik chose to keep the old price with the same discounts for the variant swap - one of three pricing options in the Swap Product Variants action (keep old price with same discounts / use new variant price / custom pricing).

• Selected 'Keep the old price with the same discounts' in Swap Product Variants action

"Let's just keep the pricing same, same because we don't want the customers to get offended."Hardik

"if I bought something on $50 and if I'll be getting charged $60 without getting any previous communication, I will get off in debt"Atul Amresh

Selling plan blank carries forward existing plan; quantities differ (1+1/2+2/3+3) and were NOT adjusted - root of 3PL fallout

Atul explained that leaving the selling plan field blank in Swap Product Variants carries forward whatever selling plan is on the subscription. Atul probed whether quantities matched between old and hero variants (whey-protein 1kg-vs-2kg analogy: quantity must be manually changed in the swap). Hardik confirmed quantities are NOT the same: '1+1, 3+3... 2+2'. Despite this they ran the swap WITHOUT adjusting quantity, relying on the variant pairs to map pack-quantity to delivery interval. CRITICAL HANDOVER FLAG: post-swap fulfillment quantity correctness was never verified in this call - this is the exact root of the known downstream fallout (3PL shipping qty 1 instead of 2/3 -> chargebacks).

• Left selling plan blank in Swap Product Variants (carries forward existing selling plan)
• Ran swap WITHOUT quantity adjustment despite differing pack quantities

"whatever the selling plan is currently on the subscription, the same will be carried forward if you keep it as blank"Atul Amresh

"quantity one plus one, three plus three. Oh my God, two plus two. So I think quantity is not same"Hardik

First bulk Swap Product Variants run failed for 13 of 15 subscriptions due to incomplete variant mapping

Hardik ran the first bulk operation with conditions selecting all three old variants (active condition removed so paused/cancelled were included) but created only one Swap action pairing (three-month old variant to hero three-month variant). The operation started successfully but history showed 13 of 15 failed, 2 succeeded; the failed CSV (column E) read 'Unable to find any subscription line for product variant'. Atul diagnosed: the condition pulled all 15 across three variants, but the action mapped only one variant, so the other two failed (no swap pair). Hardik had also misunderstood that leaving the selling plan blank would auto-map quantities; Atul clarified each pair must be created explicitly.

• Ran Skio Bulk Operations 'Swap Product Variants' (first attempt, partial/failed)
• Downloaded failed list CSV (failure reason in column E)

"in the condition, we selected all the variants... it selected 15 subscriptions, right? But in the action, we just selected... you forgot to make the pair"Atul Amresh

"Unable to find any subscription line for product variant"Atul Amresh

Second bulk Swap Product Variants run for remaining two variants (2+2 to 2-month, 1+1 to 1-month)

Hardik reran the bulk operation for the remaining variants with explicit one-to-one pairs: two-pack (2+2) to the hero two-month variant, and one-pack (1+1) to the hero one-month variant. Conditions selected only the two remaining variants (the already-swapped three-month variant unselected), active condition removed, pricing set to keep old price with same discounts. The preview showed one subscription affected. The operation was started; Atul expected full success because condition and action variants now matched one-to-one.

• Ran Skio Bulk Operations 'Swap Product Variants' (second attempt, remaining two variants)

Misleading 'failed' statuses actually reflected non-active subscriptions and a one-time $88 discount code

Some swaps continued to show 'failed' / 'unable to find product variant' in the bulk operation history, but manual checks of individual subscriptions confirmed the swaps had actually succeeded (new product showed correctly in active subscription history). Atul concluded the 'failed' status was a reporting artifact, likely because subscriptions were inactive/cancelled. For one flagged subscription, a customer had used a one-time discount code giving $88 off on three packs. Active subscriptions were confirmed working as expected.

• Manually verified swapped subscriptions via subscription history in Skio
• Downloaded success and failed CSV lists

"It's not a problem. It's more like how we are looking into the data."Atul Amresh

"maybe it is not showing because it is not active, it is cancelled... but looks like everything is working fine, like, it actually is"Hardik

Accidental selling plan group error linked all store products to subscription plans

While cleaning up (removing the deleted variant from selling plans before deleting it in Shopify), Hardik accidentally selected all products in a selling plan group instead of only the variants he intended to remove (the linked count had shown 34 before and jumped above it). This linked all store products to subscription plans, so subscription options would appear on products intended for one-time purchase only. Atul confirmed it was bad. Skio's activity log shows changes were made but not which products were added/removed, with no easy undo - an engineering-side fix would take at least a day (US-based team). Resolution: Hardik must inform the merchant and share the selling plan group link so the merchant can manually deselect the one-time-only products.

• Selling plan group product selection (accidental select-all)

"Of course, a bad thing. Like if they don't want to offer subscription for some of the product, because for some product, they want to just offer one time purchase."Atul Amresh

"it is purely on engineering side and it is like, it will take some time, like at least a day for them to like go through it because our engineering team is like a US team"Atul Amresh

Skio data-model sequencing: delete variant in Shopify removes it from product page, but still remove from Skio selling plans; wait for bulk op to complete first

Atul clarified that deleting a variant in Shopify removes it from the product page so no new subscriptions can be created on it, but it remains good practice to also remove it from the Skio selling plans. He warned to wait for the bulk operation to fully complete before deleting in Shopify, otherwise the swap fails. Operational sequencing rule for the handover playbook. Segment timestamps display in CET / Central European Time (consistent with the Switzerland-based brand owner).

• Sequencing rule: confirm bulk op complete BEFORE deleting variant in Shopify, else swap fails
• Remove variant from Skio selling plans in addition to Shopify deletion

"If you delete from Shopify, then it owns on the product page. So no one will be able to create new subscriptions. But still, it is a good practice to remove from Skio selling plans as well"Atul Amresh

Next steps: delete old variants in Shopify and Skio, fix selling plan error, follow-up Monday

Action items at call end. Hardik to: inform the merchant of the selling plan error and provide the group link for manual correction; delete the old product variants from Shopify (after bulk op confirmed complete) and remove them from Skio selling plans so no new subscriptions are created. Atul to send an email template for the backend swap and request Shopify variant IDs, loop in the Skio MSM, and connect Monday to review final status. Remaining few failed/manual subscriptions could be handled manually in the Skio dashboard given the low volume.

• Planned: delete old variants in Shopify + remove from Skio selling plans
• Planned: manual subscription swaps in Skio dashboard for remaining failures

Skio meeting prep doc authored - mapping tracker rows to Nikita-call issues

Hardik authored a prep doc before his first meeting with Elliot. It maps overlapping tasks already in Elliot's tracker (shared Google Sheet, id 129ynNugoYBUA8kijItKP7vqXPNa-YMT7yrTUucx1lAw): Row 2 'Align Shipping Interval with product quantity' (Not Complete, Priority 1), Row 3 'Delete product variants and move to new variants' (Not Complete, Priority 1), Row 8 'Improve Cancel flow sub-reasons and treatments' (Not Complete, Priority 1). The Dec $0 billing discount issue is marked partially addressed. Items marked complete: Row 9 (Add SplashScreen), Row 15 (Cancel flow conditions for orders <3 and >3), Rows 16-17 (Payment recovery billing retries). Planned questions for Elliot include how to bulk-fix existing subscriptions with discount > order value and how to migrate existing subscribers to the new variant structure without breaking discounts.

• Row 2: Align Shipping Interval with product quantity (Not Complete)
• Row 3: Delete product variants and move to new variants (Not Complete)
• Row 8: Improve Cancel flow sub-reasons and treatments (Not Complete)
• Row 9: Add SplashScreen (Complete)
• Row 15: Cancel flow conditions for orders <3 and >3 (Complete)
• Rows 16-17: Payment recovery billing retries (Complete)

Ka-ching bundle hard-coded discount exploit (quantity editing) confirmed

Ka-ching bundles hard-code the discount onto the subscription. Customers can edit quantity in the Skio portal; reducing from 3 to 1 leaves the $88 Ka-ching discount applied, yielding a free product ($0/negative orders). Proposed quick fix: disable quantity editing in portal settings. Hardik planned to ask Elliot whether quantity editing can be disabled, how to bulk-fix subscriptions where discount exceeds order value, and the recommended Ka-ching+Skio integration approach. NOTE: the $88 (Ka-ching exploit) and $92.88 (Dec disaster) discount figures are cited separately; whether they are the same hard-coded discount is unclear.

• proposed: disable quantity editing in Skio portal settings
• proposed: bulk-fix subscriptions with discount > order value

Deleted product variant causing processing issues (pre-Hardik Slack history)

A deleted product variant exists in active subscriptions and is causing processing issues. Flagged as critical context from Slack history that happened before Hardik joined. Whether subscriptions are still tied to deleted variants is an open audit question for Elliot.

• deleted variant present in active subscriptions

MRR vs actual recurring revenue gap flagged ($1.6-1.7M MRR -> $554K realized)

Nick flagged that $1.6-1.7M MRR was only producing $554K in actual recurring revenue, roughly a 3x difference. Listed as critical context from Slack history. Tied to the discount exploits and billing issues eroding realized revenue.

Cancel flow currently offers escalating discount ladder 20%->30%->40% with no frequency-change option

The existing cancel flow offers discounts (20% -> 30% -> 40%) but does not offer a frequency change/downsell. This is the baseline the proposed 'Switch to 1 pack/month at $57.99' save offer would augment. Open question: 'How do we improve the edit frequency option in cancel flow?'

• current cancel flow save offers: 20% -> 30% -> 40% discount ladder, no frequency-change/downsell option

Post-purchase upsell overstocking 3-pack orders, accelerating churn

The current post-purchase upsell adds MORE product to already-3-pack orders, accelerating churn because customers have too much product. Proposed fix: cross-sell a different product (Gut Capsule) instead of overstocking gummies. Directly tied to the ~4,000 'too much product' cancellations. Open question for Elliot: whether the upsell is on Skio's side or a separate app.

• post-purchase upsell adds product to existing 3-pack orders (overstocking gummies); proposed fix: cross-sell Gut Capsule instead

Customer portal UX problems blocking retention adjustments

Portal issues found walking the customer journey: 'No easy way to change frequency' (only shows 'deliver every 1 month'), confusing skip options ('Skip next order 2 weeks or 1 month'), a random 'Ship as gift' feature that doesn't make sense, and 'easy to cancel, hard to adjust' (buttons prioritize cancellation over retention). Proposed (Priority 3): customize portal buttons to surface 'Change to every 3 months', hide/remove quantity edit, and trigger retention offers BEFORE the cancel button.

• proposed: customize Skio portal buttons to prominently show 'Change to every 3 months'
• proposed: hide/remove quantity edit option in portal
• proposed: trigger retention offers before the cancel button

Copy/display issues: stale Valentine's page, weak $8 savings, unclear cadence

Display/copy bugs: 'Valentine's Day sale page still shows New Year sale text'; 'Subscription savings shows $8 saved - not impressive enough'; 'No clarity on checkout about cadence (am I charged monthly? every 3 months?)'. The stale-promo copy bug ('New Year sale' on the Valentine's page) is flagged as an immediate quick-win fix.

Cancellation reason breakdown over last 60 days

From the last 60 days, cancellation reasons: 'Subscribed by accident' 7,000 people; 'Too much product' 4,000; 'Too expensive' 4,000. The first two are tied to the offer-structure issue and expected to drop once the variant setup is fixed. Success-metric targets: 'Subscribed by accident' 7,000/60 days -> <2,000; 'Too much product' 4,000/60 days -> <1,000.

Retention cohort benchmark Nuora vs BioRoot Labs

Nikita pulled cohort analysis comparing Nuora retention to BioRoot Labs (biorootlabs.com, referenced as 'Jacob/J for Jacob' - a competitor benchmark, NOT Nuora and NOT Bloomin): Month 2 ~63% vs ~76% (-13%); Month 3 ~32% vs ~52% (-20%); Month 5 ~17% vs ~48% (-31%). The gap compounds; fixing shipping-interval alignment is expected to close a chunk. Success-metric targets: Month 2 retention ~63% -> 75%+; Month 3 ~32% -> 50%+. Also flagged: reduce 'subscribed by accident' cancels from 7,000, 'too much product' from 4,000, and drive free/exploit orders to 0.

Data requested from Elliot for the first meeting

Hardik plans to request from Elliot: (1) cancellation reason breakdown last 90 days (7,000 'subscribed by accident' already seen), (2) list of subscriptions with discount > order value to fix urgently, (3) churn cohort analysis - month-over-month retention by signup date, (4) current payment recovery rate (Slack mentioned 32% in November). Also raised: status of the 25-day dunning-window extension and the Klaviyo Failed Billing Attempt flow.

• request: cancellation reason breakdown (last 90 days)
• request: list of subscriptions with discount > order value
• request: churn cohort analysis (MoM retention by signup date)
• request: current payment recovery rate
• raised: 25-day dunning window status, Klaviyo Failed Billing Attempt flow

Variant migration plan set as call agenda item

Hardik queued the variant migration as a core call topic: walk through the proposed 1/2/3-month variant setup, the migration path for existing subscribers, how to handle discounts during migration without another $0 billing situation, and a timeline estimate. Nikita referenced Omre and Ankhway as examples for the new variant structure. Explicitly flags the risk of repeating the $0 billing exploit during migration.

Hardik sends Skio alignment notes to Elliot Mitchell ahead of call

Hardik (CRO) wrote a notes document to Elliot Mitchell (Skio Account Manager) to align before a scheduled Skio meeting (month-level date; no day given; the doc header literally says 'February 2025', resolved to Feb 2026 via source hint). He confirmed that, after reviewing Elliot's tracker and Slack history, Elliot was already aware of the core issues and aligned on priorities (shipping interval alignment, variant restructure, cancel flow, payment recovery), then flagged additional items and posed questions for Elliot.

Strategy call with Nikita on subscription infrastructure (pre-prep-doc)

Hardik attended a strategy call with Nikita doing a deep dive into subscription infrastructure, customer journey, and retention data (no day given in source; before the prep doc was written). Surfaced root causes (3-packs shipping monthly instead of every 3 months, need for 1/2/3-month variants, cancel flow) and additional issues (portal UX, quantity-editing exploit, upsell strategy). Nikita referenced Omre and Ankhway as examples for the new variant structure.

Quantity-editing free-product exploit reproduced live on call

On the strategy call the team reproduced the discount exploit live: reducing quantity from 3 to 1 in the customer portal leaves the Ka-ching bundles $88 discount applied, producing $0 or negative-value orders. Nikita placed a test order, went to the portal, reduced to 1 pack, and saw free product. Hardik flagged it urgent and asked Elliot whether quantity editing could simply be disabled in portal settings as an immediate fix. (The exploit paragraph does not itself name 'gummies'; the 3-pack-gummies link is supported elsewhere.)

Cancel flow walkthrough aligned as tracker Row 8

Hardik and Nikita walked through the entire cancel flow on the strategy call, confirming it maps to tracker Row 8 (improve cancel flow sub-reasons and treatments). Portal UX problems flagged: 'edit frequency' only shows 'deliver every 1 month' (no 2/3-month option); confusing skip options; a random 'Ship as gift' feature; buttons prioritizing cancellation over retention. Payment-recovery topics also raised: current 32% recovery rate, the recommended 25-day dunning window, and a Klaviyo Failed Billing Attempt flow.

Core team strategy call: subscription/Skio infrastructure deep-dive (100 min)

Hardik, Nikita and Ollie held the weekly core team strategy call (~100 min). Nikita walked through Nuora's subscription/offer problems from the technical perspective: the Kaching Bundles + Skio discount exploit, monthly shipping of 3-pack subscriptions, the customer portal cancel/edit-frequency flow, and the post-purchase upsell. Goal: record the constraints once so they could be fixed at root cause and never revisited. Nikita repeatedly told Hardik to coordinate directly with Elliot (Skio account manager) and walk the full customer journey on every test. Outputs also fed the prep doc (fix shipping cadence, move to 1/2/3-pack variants, fix cancel flow, fix Ka-ching exploit), plus new issues not in Elliot's tracker (portal UX, quantity-editing exploit, upsell overstocking, stale Valentine's/New Year copy, Month 3 retention gap).

Core-team call: Nick coaches first-principles and second/third-order thinking

On the 2026-02-03 core-team call (the earliest Fathom call referenced in the L60D case file), Nick told Hardik to 'be more curious, dive more into data, think more first principles, think in second and third order consequences.' Sets the coaching baseline that recurs through the period.

• Coaching: first-principles, data, second/third-order consequences

Kaching Bundles + Skio quantity-reduction exploit re-confirmed ($88 free-product bug)

Nikita and Hardik confirmed the core exploit: Kaching Bundles hard-codes a discount on the subscription, and when a customer reduces quantity on Skio (e.g. 3-pack to 1) the hard-coded discount is retained, so the order bills $0 and they get product free. Nikita demonstrated live: a customer's subscription showed an $88 discount; reducing it from quantity 3 to 1 produced a free product. Nikita called it 'the number one' constraint and noted Skio lets you switch off the customer's ability to edit quantity as one workaround.

"Because Ka-ching bundles, they always hard code. If you have a code subscription, then if you reduce the quantity, it [messes] it up."Nikita Lienov

Hardik reports moving all product subscriptions onto main hero SKU as exploit fix

Hardik said he had 'streamlined everything' and updated Keira: he shifted all subscriptions across other products onto the main hero product SKU so frequency is properly tamed and the discount exploit is contained. He demonstrated in Skio that other products' active-subscription counts now show zero and said the remaining few would migrate to the top SKU within a day or two. He stressed total subscriber count was unchanged. (The verbatim line appears under Nikita's timestamp but reflects Hardik's described action; speaker attribution uncertain.)

• Transferred all subscriptions from other products onto main hero SKU product in Skio

"So I have just transferred the subscription from all the products to the main hero SK product."Hardik Dewra (attribution uncertain)

Skio Segments CSV export of active subscriptions ('3rd February export')

Nikita and Hardik exported subscriptions out of Skio. Creating a Segment exports all subscriptions for a given SKU; they ran an export with 'Include active subscriptions / All time' (an offset of ~18,000 was mentioned during processing; slow). The file was labelled 'Active subscriptions, 3rd February export'. Nikita scanned columns (subscription line quantity, discount amounts, payment method, shipping address) and confirmed customers with quantity 1 but an $88 discount, plus customers who had gone through multiple billing cycles getting free product. (Skio's API rate of 2,000 requests/min is an ambient remark, not a measure of this export.)

• Skio Segments CSV export of active subscriptions (All time) - '3rd February export'

Elliot's variant-restructure recommendation discussed (1/2/3-month variants)

Nikita relayed Elliot's workaround for the Kaching-vs-Skio problem: instead of quantity-based subscriptions, use different variants where one month = 1 quantity, two months = 2 quantities (1x = 2 packs), three months = 3 quantities. Hardik confirmed Nuora already does this on the Gut Capsule (one variant per product count). Nikita flagged supplier/coordination risk - the supplier must know '2 months' means the customer gets 2 packs.

• Proposed: replace quantity-based subscriptions with 1/2/3-month variants

"We already tried it in gut capsule. That is what we do... One variant for one product, two variants... another variant two products, another variant three products, the third variant."Hardik Dewra

Live customer-journey walkthrough exposes portal cancel/edit-frequency defects

Nikita walked the full customer journey live: bought a 3-pack gummies subscription ($58.99), through checkout (free shipping, ~$79 charge - audio garbled), saw a post-purchase upsell offering more free product, then the Skio customer portal. Findings: order summary confusingly shows 'one month, three packs'; cancellation has a confusing 'skip next order two weeks or one month'; the cancel flow offers escalating discounts up to 40% off (bringing a 3-pack to ~$35); critically, 'Edit frequency' only allows 'deliver every one month' with no easy quarterly option. The checkout page itself cannot be edited by Hardik, Tomide or Tomi.

"if I click edit frequency, I can only change to deliver every one month. You see? Another [messed] up. There is no way for me to easily change the frequency to every three months."Nikita Lienov

Monthly-shipping-of-3-packs identified as root-cause offer defect

Nikita identified the deepest root cause: a customer who buys 3 packs gets billed/shipped every month instead of once every three months. Hardik agreed it should ship after three months. Nikita called it a bad offer that sells product too cheap and drives cancellations and overstocking; fixing shipping cadence at root means the problem never recurs. He tied this to the upsell overstocking customers, pushing them into Skio to reduce quantity (triggering the discount exploit) or cancel.

"When customer buys something, they buy three packs, they get [shipped] every month instead of one month for each pack."Nikita Lienov

Cohort retention benchmarking vs biorootlabs.com reveals ~2x churn gap

Nikita ran Skio cohort analysis and benchmarked Nuora against biorootlabs.com ('Jacob/J for Jacob' - competitor, NOT Bloomin). Nuora December cohort: 90% active at end of month 1, ~63% retained to month 2, ~32% by month 3. BioRoot's comparable cohort retained ~97% (month 0/1), ~72% by month 2, ~70% by month 3 (their 'month 0' aligns to Nuora's 'month 1'). Granular month-by-month comparisons: Nov 93% vs 96%; Oct m1 91%; Sep 94%, Aug 94%; Oct m2 44% vs 68%; Sep m2 53% vs 72%; Aug 48% vs 22%; Nuora m3 25%/31% vs BioRoot m3 52%. Nikita attributed the gap to the broken offer/cadence, not the product (~2000 reviews, 4.2 stars).

Skio cancel-reason breakdown reviewed (Dec 2025 - Jan 31 2026)

Nikita reviewed Skio's cancellation reason breakdown for December 2025 through January 31, 2026. Top reasons: 'I subscribe by accident' lost ~7,000 with only ~2% (2.3%) saved by the cancellation flow; 'I have too much product' lost ~4,000; 'too expensive' loss-count is unreliable (source garbled, fragments '6' and '4,000' both appear) - do not state a single figure; the splash-screen flow retains ~90%. High accidental-subscribe and too-much-product reasons are direct evidence of the offer/cadence problem and a weak cancellation flow.

Past bulk operation that caused free orders referenced by Nikita (~500 people)

Nikita recounted a prior bulk operation on ~500 people where he reduced pricing (to ~$58) and changed quantity from 3 to 1. The next day subscription payments halved and hundreds of orders went out free, because the bulk op did not remove the hard-coded discount. Correct method: when removing a discount in a Skio bulk op you must specify the discount name and remove only that named discount. Used as the cautionary lesson for why Skio support/Elliot must be looped in. Date of the original op is not given (retrospective reference during the 3 Feb call).

• Past Skio bulk operation: reduce price ~$58, change quantity 3->1, discount not removed -> free orders

"I reduced their pricing... and I changed from quantity three to quantity one... then next day, I wake up, we have half as less subscription payments... hundreds and hundreds of people who got orders for free."Nikita Lienov

Competitor benchmark numbers (biorootlabs/Grants) explicitly NOT Nuora

HANDOVER FLAG: Nikita cited '$174 million on Shopify', '75% of revenue is Skio subscriptions', and '83% average order value' - these belong to the competitor/benchmark brand (biorootlabs.com / 'J for Jacob'), and separately Grants (~$200M/yr, 4 brands Neutrops/Juiced/etc). These are NOT Nuora figures and a handover reader could mistake them. Also Nuora media-spend context: ~$60,000-67,000/day Facebook spend, up ~30% seven-to-seven (~$100,000/week extra).

Hardik turns off Kira-shared variation/PDP split test blamed for CVR drop

Ollie flagged overall CVR had dropped. Hardik identified the cause as the Kira-shared variation page split test (running ~1 day 18 hours) and turned it off live. Ollie argued split-testing different PDPs (medical vs dryness vs odor/main hero) breaks because specific Facebook traffic is routed to specific PDPs, so redistributing traffic distorts results. An analytics/CRO test, not a Skio subscription change.

• Turned off Kira-shared variation/PDP split test

Ollie given Shopify access for the first time; ~5,000 unfulfilled orders noticed

It surfaced that Ollie (media buyer) had never had Shopify access. Nikita added him as a user so he could see the source-of-truth CV-by-LP report and Shopify analytics for diagnosing CVR/ROAS. While in the users panel Nikita noticed ~5,000 unfulfilled orders. Not a Skio operation but relevant to ops access/fulfillment.

Nikita exported active Skio subscriptions for analysis (resources list)

Per the prep-doc resources section, Nikita exported active subscriptions from Skio on Feb 3rd for analysis (the 'Skio Subscription Export' resource Hardik is working from). Year is 2026 (doc header '2025' is a typo). This is the same '3rd February export' referenced on the call.

• Skio active subscription CSV/export for analysis (Feb 3)

Hardik's account/credential compromise from running a script (NOT a Skio operation)

At call end Hardik says his passwords/accounts got hacked/stolen because he 'ran some script', and references Claude ('Did Claude not hack here? Was it Claude?'). This is about Hardik's personal credential compromise, NOT Claude/AI being used to run or analyze Skio operations. There is NO Claude/AI-subagent usage on Skio operations anywhere in this transcript.

Planned Monday call with Elliot (Skio account manager)

Nikita said the team has a call scheduled with Elliot the following Monday and invited Hardik to join. Hardik said the prior Skio support contact ('that Indian guy') did not know what he was talking about and he needed to connect with Elliot directly; Nikita said he would add him. Action item: share the 3 Feb Skio export with Elliot, then analyze discounts/churn and propose fixes. Date inferred as the Monday after the 3 Feb (Tuesday) call = ~9 Feb 2026.

• Planned: analyze 3 Feb Skio export with Elliot; propose subscription/discount/cadence fixes

"That Indian guy did not know what he was talking about. I need to connect with Elliot."Hardik Dewra

Kaching Bundles permission block on Shopify; Hardik pushes to move off it to HTML/CSS

At the start of the weekly core team strategy call, Nikita explained Kaching Bundles sometimes updates its required app permissions, creating a block until you accept them. Hardik said the Kaching Bundle approach was not sitting well with him, called it inefficient, and said going forward they would move to the HTML and CSS approach so it would no longer be an issue. Nikita refreshed the app permissions during the call so it would work again.

• Kaching Bundles app permission refresh on Shopify

"But this Kaching bundle thing is not really sitting well with me. It is like so inefficient. Right now, what is working is working."Hardik

Hardik briefs team on the Elliot subscription-interval fix: move 3/2/1-packs from monthly to every 3 months and migrate subscribers

Hardik explained the subscription work he is doing with Elliot. Currently they ship 3-packs, 2-packs and 1-packs every month; he and Elliot agreed to increase the interval so e.g. 3-packs ship every three months. Plan: migrate all current 3-pack-every-1-month subscribers to a new 3-pack-every-3-month variant, remove their coupon codes (which are making them cheap), and set a new price. Hardik flagged that churn will rise initially as subscribers used to monthly packs suddenly get them less frequently; Elliot told him there will be a slight initial drop then growth over time. Status update ahead of the Feb 11-24 migration window.

• Planned subscriber migration from 3-pack-every-1-month variant to 3-pack-every-3-month variant
• Planned removal of existing coupon codes on migrated subscriptions
• Planned new pricing on migrated subscriptions

"So now we'll be setting three packs every three months. Now, currently, whatever subscribers we have, which are on three packs every one month, we will be migrating them all and removing all the currently coupons they're having."Hardik

Nikita lays out two migration options and a cancellation discount ladder; recommends data-first analysis and a 3-5 day 50/50 test

Nikita argued a longer interval (e.g. 3-packs every 3 months) would drop revenue but not necessarily subscriber count, since subscribers are charged less often. Option one: switch everybody onto the right cadence/variant. Option two: take everyone on two-month and one-month supply, remove the discount, switch them to one-month supply, keep price slightly lower or same, exploiting the existing 3-packs-for-$58 pricing for high short-term margin. He described a cancellation-page discount ladder of $34.99 then $29.99 (good stopping point). He warned a similar past change made many customers message support asking why they only got one pack that month. Recommended: pull raw historical churn data (by cadence and by 1/2/3-pack) with Claude, map scenarios over 3 months, then run a small ~3-5 day test with 50% getting the change. (Transcript garbles the test/control split as '50%...50%' - control arm is interpreted, not explicit.)

• Proposed churn-rate analysis by cadence and pack size using historical data with Claude
• Proposed 50/50 split test over 3-5 days before full rollout
• Proposed cancellation-flow discount ladder ($34.99 -> $29.99)

"So that's why you need to test on a smaller amount of customers first. So you just need to analyze the data very carefully, take this transcript and then analyze the data very deeply with raw data, not assumptions."Nikita

Hardik flags data pollution: quantity-reduced 3-pack subscribers now appearing in the 1-pack option

Hardik raised that customers who originally bought the 3-pack-every-1-month variant then reduced quantity to 1 now appear under the 1-pack option, polluting the data (genuine 1-pack subscribers mixed with quantity-reduced former 3-packs). He still has to remove the discounts on these and would resolve details with Elliot on the next Tuesday call. Describes the SKU/variant mismatch caused by quantity-based subscription edits.

• Identified quantity-reduced 3-pack subscribers polluting the 1-pack variant data
• Planned discount removal on these subscriptions

"People who purchased with intent of buying three packs for every one month, they reduce the quantity and now they are getting for the data is also flawed. So data is not pure."Hardik

Ollie notes shipping cadence is a double-edged sword for subscription retention

During the cadence discussion, Ollie noted every shipment is a double-edged sword: good that subscribers receive product, but each shipment also reminds them they are on a subscription and can prompt cancellation. Nikita agreed and tied it to email marketing - if subscribers do not remember they are subscribed, then after three months they receive product and, with good email marketing, will not unsubscribe.

"It's a double-edged sword because every time they're shipped as well, it's a good thing they're getting the product but it's also a reminder that they're on a subscription."Ollie

Nikita grants Hardik expanded Shopify admin permissions via a new staff role

Nikita created a new Shopify staff role and granted Hardik much broader admin access across ~60 permissions (abandoned checkouts, draft orders, products, gift cards, customers, companies, markets, files, metaobjects, checkout, analytics, online store, app development, store settings, apps). Hardik had reported he couldn't delete archived products, change the checkout/top logo, and that orders showed '9,999+'. After the role applied the count displayed '10,000'. (Distinct from the SUPPLIER's separate '10,000+ orders' manufacturing backlog. The list also includes 'Binance' - likely a mistranscription - and 'Access, location, domain'.) This grant enabled subsequent SKU/subscription cleanup work.

• Created new Shopify staff role and assigned Hardik with full app access

Nikita wants to brief supplier on 'variants thing'; Hardik added to Lucky supplier WeChat group

While sorting Hardik's access, Nikita said he wanted to connect to the supplier 'because I want to tell him that variants thing' - tying the supplier/fulfillment side to the variant restructuring work. Nikita added Hardik to the supplier (Lucky) group: the supplier ignores Discord but checks WeChat, so Nikita texts her in WeChat and added Hardik ('Lucky. Permissions. And then we add members. Done.'). Relevant because variant/SKU changes have a fulfillment/supplier dependency (Lucky = fulfillment ops).

• Added Hardik to the Lucky supplier WeChat/Discord group to coordinate the variants issue with the supplier

Supplier order backlog: ~10,000+ orders on supplier end, slow due to Chinese New Year

Hardik flagged the supplier showing '10,000 plus orders' and 'not processing fast' because the Chinese New Year month had started; he asked Nikita to push the manufacturer to process faster. Fulfillment/manufacturing-ops context bearing on subscription shipments. Distinct from the Shopify-admin '10,000' order-count display.

Claude subagents used for ad/blog ingredient-story research (~3 subagents) - NOT a SKU/Skio op

During the ads/copywriting portion, Nikita ran Claude to research ingredient stories (bromelain/bromine, bacillus coagulans, pineapple): 'Let it just cook. Three sub-agents.' and later 'Oh, two agents finished?'. Captured per the rule to log Claude/AI subagent counts, but this is ad/blog research, NOT a SKU/Skio/subscription operation - no subscription data was processed by these agents.

• Ran ~3 Claude subagents to research ingredient/historical stories (pineapple, bromelain, bacillus coagulans) for advertorials/blog - not a SKU/subscription operation

Subscription migration window begins: consumption-matched billing rollout (Feb 11-24)

Nuora began the Feb 11-24, 2026 subscription migration window to align billing frequency to consumption rate. Multi-pack subscribers previously billed monthly were switched so 3-pack subscribers bill every 3 months (quarterly), 2-pack subscribers bill every 2 months (bimonthly), and 1-pack subscribers stay monthly (unchanged). Product quantity per shipment and revenue per shipment stayed the same; only billing frequency changed. This delayed billing dates by 1-2 months, shifting (not losing) revenue from Feb/March into April/May. Driven by overstock-related churn ('I have too much product' = 16.6% of cancellations). Nominal pack price points from the migration summary: monthly 1-pack $34.99, bimonthly 2-pack $49.99, quarterly 3-pack $58.99. Per the compaction summary the migration was run WITHOUT first doing the before/after contrast analysis Nick had explicitly requested - the central conflict. Migration_start constant = 2026-02-11.

• Skio bulk operations: billing interval change on multi-pack subscriptions (3-pack monthly -> quarterly; 2-pack monthly -> bimonthly; 1-pack unchanged)
• consumption-matched billing migration

Three batch migrations executed via Skio bulk operations with old->new product ID swaps

The 'Nuora Optimisations - Bulk Operations Stuff.csv' documented three batch migrations, each mapping an old product ID to a new product ID, with bulk operation IDs (the operation IDs themselves were not surfaced in the recovered text). Batch 1 (Medical Gummies): product 8343955144844 -> 8982209200268. Batch 2 (Black PDP): product 8338864701580 -> 8981965897868. Batch 3 (Highest Converting PDP): product 8105143369868 -> 8974140440716. These are the variant/product swap operations behind migrating existing subscriptions onto the new product structure with consumption-matched billing intervals.

• Skio bulk operations: product/variant swap across 3 batches with documented old->new product IDs and bulk operation IDs

Discord: Nick asks root cause after Hardik already spoke with Lucky and Rei

After Hardik had already spoken with Lucky and Rei (fulfillment ops), Nick still had to ask 'whats the root cause'. The only event in the L60D file naming Rei, and the only one tying Lucky+Rei to a specific dated incident. No further operational detail in source.

• Root-cause prompt after Hardik consulted Lucky and Rei (fulfillment ops)

Recurring Skio catch-up calls between Hardik and Elliot Mitchell

The inbox contained 8 zcal calendar reminders for a recurring 'Skio Catch-up (30min): Hardik Dewra and Elliot Mitchell' (notifications@zcal.co), plus 8 'Recap of your meeting with Skio' Fathom recaps (Updates tab) and 3 in Primary. One reminder references a Wednesday in February. Confirms an ongoing cadence of Skio working sessions through the Jan-Mar 2026 cleanup; specific dates/contents beyond 'Wednesday, F[eb]...' not captured. Date set approximately to mid-Feb 2026.

Discord: plan to add more SKUs after CNY

In a forwarded Discord message dated 15/02/26, Nick noted AOV was looking better and that the next page most people navigate to is 'shop all', concluding they need MORE SKUs for more customer touch points; they would wait until the end of Chinese New Year then get more SKUs. A later embedded note (02/03/26) from Hardik adds that with two SKUs the current KnoCommerce plan (two live surveys) is sufficient, but more SKUs would require KnoCommerce premium.

"ok will wait for end of CNY and after CNY we gotta get more SKUs so our customer can have more touch points in her life"Nick

Prior call with Elliot reviewing the Skio backend

Hardik referenced a call he had with Elliot the day before (relative to Feb 17), during which Elliot 'showed me everything' in the backend. On Feb 17 Hardik said he was checking that recording. (Elliot's Skio account-manager affiliation comes from external context, not this transcript.)

Core team strategy call walkthrough of SKU/migration plan (Milanote workflow)

Hardik presented his Milanote migration workflow, screensharing the plan to move all traffic off Kaching Bundles to new Replo pages. He identified the Shopify backend shows many active SKUs while there are two main products: Gut Capsule and Gummies. Primary goal: get rid of Kaching Bundles and route traffic to new Replo pages. Metrics noted in passing: '8,000 unfulfilled' (supplier/Chinese New Year delay, not a migration metric), 'over 3000 ads going to the URL' (ads pointing to the old product URL that cannot be switched).

• Migration planning (Kaching Bundles to Replo pages)

Old Gut/medical PDP flagged: wrong selling plan, 3-packs shipping monthly

Hardik flagged the old medical/Gut PDP product as using the wrong selling plan, wrong variant names, wrong pacing, wrong cadence, and Kaching Bundles. 'Wrong' = it ships three products every month instead of three products every three months. The correct new Replo page uses every-1-month/every-2-month/every-3-month variants. Product ID and link documented in the Milanote workflow. A/B testing showed only marginal difference between control and the new Replo page, with the new page making more money on some pages. (Gut Capsule label inferred from earlier two-main-products framing, not explicit at this flag.)

• Selling plan / cadence fix (planned)

"it ships three products every month instead of three, three products, every three months"Hardik Dewra

Old Gummies PDP flagged: missing 2/3-month variants, new Replo page winning

Hardik flagged the old Gummies PDP (the 'old black woman PDB product page') as wrongly attached: it says gummies every one month but lacks every-two-month and every-three-month options. Product ID and link documented. The new Replo test page outperforms control, does not use Kaching Bundles, and has correct pacing, selling plan, and variant naming.

• Selling plan / variant fix (planned)

Planned subscriber migration of two small SKUs to new variants

Hardik laid out his migration plan ahead of the 9pm IST Elliot call: migrate existing active subscribers on the old SKUs to the new variants/SKUs. For the one-month variant he would discard all discounts and set a baseline price; for the two-month and three-month variants he would just switch the variant itself. These two SKUs both have few active subscribers, so he would monitor them first (retention/churn) before touching the main SKU with over 30k active subscribers (62k+ active total), which he did not want to touch yet. Gummies base is 'less than 1,000'; a count of '325 yesterday' was mentioned for 'this one and this one' (variant ambiguous).

• Subscriber migration to new variants (planned)
• Discount removal + baseline price on 1-month variant (planned)
• Variant swap on 2-month and 3-month variants (planned)

Scheduled Elliot call at 9pm IST to execute changes

Hardik said he had a meeting with Elliot at 9pm IST on Feb 17 to implement the new changes: route traffic to the new Replo links instead of the old product links, and coordinate the subscriber migration and the 3-pack billing change. (Elliot's Skio affiliation comes from external context, not this transcript. Whether this call executed and its outcome are not in this source - pre-execution.)

Decision: change 3-packs to quarterly billing and delay billing by two months

Hardik relayed Elliot's suggestion for people currently getting three packs every month: change them to three packs every three months, and delay their billing two months into the future (e.g. a customer due 1st March moved two months later). Rationale: if a customer already has product and gets charged again without a shipment for three months, churn rises; delaying billing reduces churn. Nikita raised concerns about the short-term revenue effect; Hardik acknowledged a short-term impact but argued people would stay and pay later rather than cancel. (Quote is a stitch of two separate fragments.)

• Billing interval change (monthly to quarterly)
• Billing date shift (+2 months)

"instead of three packs every month, I'll change to three months for three packs ... he will delay the billing to two months"Hardik Dewra

"I have concerns about the revenue effect, the effect on the revenue."Nikita Lienov

Kaching Bundles identified as root cause of billing/discount mess (during flawed <$10 Shopify export)

Reviewing a Shopify export of customers paying less than $10, Hardik said the root cause was Kaching Bundles ('catching windows thing'), because it hardcodes the discount and everything gets messier; he wanted to move off it. Nikita noted the discount can be removed from Skio. Hardik countered there are many named discounts (two packs, three packs, etc.) complicating removal, and worried about customers on legitimate discounts. The Shopify export turned out flawed (it exported every order from every customer, ~300,000), so the data was set aside as irrelevant. (The '$0/sub-$5' framing belongs to the separate Claude/Telegram event.)

• Discount removal from Skio (discussed)
• Shopify CSV export (flawed)

"The root cause is the catching windows thing ... because it hardcodes the discount and then everything just gets messier and messier."Hardik Dewra

Nikita uses Claude bot (Telegram harness) to export sub-$5 loophole customers

Nikita demonstrated using a 'Claude bot' (a Claude Code harness running in Telegram on his local device, 'CloudCode but with more tools', under the hood Claude Opus 4.6 via API) to investigate the billing loophole. He prompted it to check its Shopify API access (orders/export) and pull an export of customers from the last 60 days who got a product where total paid price is below $5 - customers who found a loophole to get products free. Order-count metrics (9k/100k in 60 days/20k) are Nikita's loose recollection of past bot queries, not a precise result of this export.

• Claude bot (Telegram harness) Shopify order export (loophole detection)

"we have some customers who found a loophole and they use this loophole to get products for free ... an export of people ... in last 60 days ... total paid price is below $5"Nikita Lienov

Claude bot (Telegram harness) capabilities, model and infra discussed

The team discussed the Claude bot itself: runs inside Telegram on Nikita's local device with access to his computer/files; under the hood Claude Opus 4.6 via API (any model connectable, including local). Nikita uses Claude because it is 'less likely to get prompt injected.' Described as a Claude Code harness ('it's just CloudCode, but with more tools'). Nikita is considering a Mac mini (vs a $5/month VPS) to run it 24/7 to monitor the ad account for anomalies. Hardik raised security concerns about filesystem access (autonomous file deletion) and speculated Nikita's repeated LinkedIn bans may correlate with bot/browser-use automation, caveating correlation vs causation.

• Claude Code/Telegram bot infra + model selection
• Proposed 24/7 ad-account anomaly monitoring (Mac mini)

"the reason why I use Claude, because it's less likely to get prompt injected"Nikita Lienov

"It's a harness, you know, so there's not much difference"Nikita Lienov

Decision to migrate subscribers off old setup to avoid Shopify Plus $30k charge

Hardik said Shopify was repeatedly asking for money for Shopify Plus (free trial ending 14 or 15 Feb). The amount asked was $30,000, tied to the recurring subscription total shown at checkout. Plan: migrate customers to the newest pages first (where the recurring sub total does not show at checkout, by adding the Skio link) so they would not need to pay the $30k. Nikita said don't give them the money and that he would figure it out, while noting Shopify Plus is worth it for checkout CRO and future fee negotiation.

• Subscriber migration to new pages (to avoid Shopify Plus charge)

"let's first migrate the people. And then we give them money."Hardik Dewra

Replo-on-/products-URL exploration to avoid switching 3000+ live ads

Nikita raised they cannot switch the product URL because over 3000 active ads point to it; switching would break configs. He proposed asking Replo whether a Replo page could render on the existing /products slug (e.g. /products/gummies) - like their advertorial app does on /pages - so the same URL serves new Replo content. Hardik agreed to explore it. Interim: Hardik plans to use the Elevate A/B testing tool to slowly shift more traffic to the variant (new Replo) page; Nikita noted Elevate works via redirects (added load time, not as clean).

• Replo page on /products slug (to explore, avoid URL switch)
• Elevate A/B test redirect traffic shift (interim)

8,000 unfulfilled orders flagged, blamed on Chinese New Year supplier delay

During screenshare Hardik flagged '8,000 unfulfilled' as not good. Nikita said he would text the supplier and attributed the delay to Chinese New Year pushing fulfillment back repeatedly; he had reminded them already with no luck and notified them again on the call. Fulfillment/ops fallout context, operationally relevant to the handover.

• Supplier follow-up (Chinese New Year fulfillment delay)

GitHub/PR workflow set up for shared Claude knowledge repo

The team agreed to upload knowledge documents to GitHub so Claude/Claude Code pulls from a shared repo. Nikita uploads a copywriting/writing document; Hardik a design document. Workflow: each member does a GitHub pull when they start working and a push when they stop. Hardik suggested sub-branches off main with a PR review step before merging rather than pushing straight to main; Nikita agreed and Ollie said he can manage it. Hardik asked to be added as a contributor. Underpins how the team operates Claude across the brand.

• Shared GitHub repo + PR/sub-branch workflow for Claude knowledge files

Subscribers mostly on main SKU one-month and three-month; gummies tiny

Hardik clarified the 62k+ active subscribers are 'on the main SKU for the one-month and three-month mostly', while the gummies subscriber base is 'less than 1,000' and '325 yesterday' was mentioned for 'this one and this one' (variant ambiguous). He intends to perfect the newly launched SKU first (more revenue) and get rid of Kaching Bundles before A/B testing just the Replo setup. Gummies traffic/ads are currently throttled because of Chinese New Year.

Variant/quantity bulk operation still running, did not complete on Feb 23

Hardik reported (on the Feb 24 call, referencing 'yesterday') that the Skio bulk operation he ran had not completed as of Feb 23 and was still ongoing when he last checked. The operation related to changing subscriber quantities/packs. Separately, cross-checking revenue, Nikita read Skio's recurring subscription revenue of 58,000 for the 23rd and confirmed it as correct.

• Skio bulk operation (incomplete/ongoing as of Feb 23)

"No, yesterday, the bulk operation didn't complete. It was still ongoing, the process when I last checked."Hardik

Skio catch-up call (Feb 23) - Elliot supportive, showed Forecast feature

Hardik shared the transcript of a Feb 23 Skio catch-up call into a later Claude session (the transcript itself not stored verbatim). Per the compaction summary, Elliot (Skio) was supportive, telling Hardik the long-term billing-interval move was correct and that retention was improving, and showed Skio's Forecast feature (projects future revenue). (The '$100k+ days into Aug 2026' figure is from Hardik's separately-shared Nuora Optimisations forecast screenshot, not stated as content of this call.)

• Skio Forecast feature used to project future revenue

Removal of free six-pack/seven-pack quantities reduced quantity per subscriber

Hardik reported quantity per subscriber had decreased because a lot of people were getting six packs or seven packs for free, and he removed those. He said total/overall subscriber value did not decrease, only quantity per subscriber. Nikita pushed back hard on the vague 'a lot', demanding exact numbers, quantity, and contrast analysis before such actions. No exact count of affected subscribers was given.

• Removal of free six-pack/seven-pack quantities from subscriptions

"The quantity per subscriber has decreased, by the way, because a lot of people were getting six packs or seven packs for free. I removed those."Hardik

"Don't say a lot. Never say a lot. Never say too much. Always say exact numbers... I want to know exact reason, exact quantity, exact contrast, exact difference."Nikita

Revenue cross-check between Skio data and Shopify actuals during call

Nikita and Hardik cross-checked subscription/recurring revenue accuracy: Hardik's reported data vs Skio vs actual Shopify revenue. Hardik showed recurring order revenue of roughly 38k/42k/36k/42k/39k/40k (~40k avg, this-year-vs-previous-year). Skio showed recurring subscription revenue of 58,000 for the 23rd. Nikita asked to switch the top dropdown from total sales to net sales. Daily figures: 20K, 23K, 20K, 44K. Ollie's data point: normally ~30k/day, today started ~17k ('basically half'). Nikita flagged daily MRR dropping to ~20K and stressed they cannot afford decreasing revenue.

• Skio vs Shopify revenue cross-check (total sales vs net sales)

"It says recurring subscription revenue 58,000... Can you switch on the top dropdown from total sales to net sales?"Nikita

Hardik to feed bulk operation data into Claude and publish reports on private GitHub

Hardik said he just got access to Claude and planned to take the bulk operation data he obtained, feed it into Claude, generate reports, and publish them on a private GitHub repository, adding Nikita and Ollie as collaborators to review.

• Feed bulk operation data into Claude
• Generate reports
• Publish to private GitHub repo with Nikita and Ollie as collaborators

"I have to just take the data that I have got in terms of bulk operation and then feed it into Claude because I just got access to Claude. And then I will just get the reports ready and then publish it on GitHub."Hardik

Decision to NOT switch subscribers from monthly to quarterly cadence; reverse course

Nikita decided against changing existing subscribers from every-one-month to every-three-month cadence, arguing it would hurt the business (waiting three months to reap benefits) and that descaling order volume risks getting cut by payment processors and increasing chargebacks. He said the action Hardik already took is reversible and easy to switch back via bulk operations. Strategic direction shifted to fixing front-end acquisition so new customers come in on the correct cadence. Subscribers were split across two cadence groups (overstocked vs every-one-month, 'nearly half or so' each); the floated option was to move people to one quantity every month while keeping the price they paid for two/three months. Hardik noted Kira had told him about the cadence idea and Nikita should update Kira that they can't do it.

• Decision against monthly-to-quarterly billing interval change
• Reversal via bulk operations flagged as easy

"If we change from every one month to every three months, then we'll essentially shoot into our own leg right away and we'll need to wait for three months to reap the benefits later on."Nikita

"What you did right now is reversible because it's easy. It's easy to switch customers... just bulk operations, boom, done."Nikita

"So Kira told me about it. So... I think you'll have to update Kira regarding that, that we can't do that."Hardik

Chargeback / capsule shipping flagged as churn/revenue-risk drivers

Ollie asked whether the primary revenue concern was the chargeback rate. Nikita said it was the capsule shipping issue plus another factor. Nikita repeatedly stressed that decreasing order volume increases chargebacks and they cannot descale without being cut by payment processors. He asked Hardik to have Claude evaluate the conversation to figure out how to avoid chargebacks while keeping order volume up.

• Chargeback risk assessment tied to order volume and capsule shipping

"Nick, what's the primary reason for that, is the main one chargeback rate?"Ollie

"charge[backs] we create is going to be increasing if the order volume is less. So we cannot, we cannot decrease the order volume."Nikita

Cohort retention analysis blocked by broken UI dropdowns (macOS update)

Nikita repeatedly tried to run a cohort/retention analysis by product ID/name in an analytics tool (appears to be Skio cohort UI) but couldn't because dropdowns/selectors were not clickable across multiple browsers. Claude later told Nikita the cause: his MacBook auto-updated to a new Apple release that broke dropdowns/selectors system-wide; advised to restart. This blocked the live revenue/retention cross-check during the call.

• Attempted cohort retention analysis by product ID/name (blocked by non-functional dropdowns)
• Claude diagnosed macOS auto-update as cause of broken selectors

Nikita instructs Hardik to give the full call transcript to Claude to evaluate cadence/chargeback decision

Near the end Nikita explicitly told Hardik to give this call transcript to Claude and have Claude evaluate the conversation to figure out how to avoid chargebacks while keeping order volume up, and how to transition subscribers smoothly. Framed as urgent ('that is for today, that is urgent'). Distinct from the bulk-operation-reports-to-GitHub plan.

• Feed call transcript to Claude for evaluation of cadence/chargeback strategy

"Hardik, please ask both to evaluate this conversation because I think it's going to be very important. And we need to figure out how we not get [cut]."Nikita

"So, figure it out and speak to Claude. Give this transcript."Nikita

Subscriber base scale referenced as ~66,000 people (illustrative)

Nikita referenced subscriber/customer scale: 'if this month we have 66,000 people, right? And a lot of them cancel...'. The only subscriber-count figure in the call, stated hypothetically/illustratively, so flagged as approximate/illustrative, not a confirmed exact count.

Gummies front-end profitability questioned; Ollie rejects cutting gummy ads to push gut capsule

Hardik suggested cutting gummy ads and scaling the gut capsule (arriving in a few days) to improve profitability since profit was dropping. Ollie rejected this: 'We are a media company... we are very dependent on getting people through the door... we cannot stop ads.' Nikita said for gummies a 1.4-1.5 ROAS is roughly break-even, not profitable. A SKU-level (gummies vs gut capsule) acquisition/profitability decision.

• Proposed cutting gummy ad spend to scale gut capsule (rejected)

"No, that's not how it works. We are a media company, essentially... We are very dependent on getting people through the door... we cannot stop ads, bro."Ollie

Gut capsule physical stock arriving in next few days

Ollie and Hardik both noted the gut capsules should arrive in the next few days. Ollie said lack of capsule footage is restricting video/storytelling content; Hardik tied capsule arrival to a plan to scale the gut capsule SKU. An operational dependency for the handover.

Migration Batch 3 completed; migration window closes (last clean data point)

Batch 3 of the migration completed on Feb 24, 2026, closing the Feb 11-24 window. As of the Feb 25 analysis there was only 1 day of clean post-migration data. The migration ran in at least three batches (Batch 3 named explicitly; total batch count not stated, 3 inferred from highest batch number). The migration delayed billing dates by 1-2 months for multi-pack subscribers, shifting revenue from Feb/March into April/May. Transition-period daily revenue ($116,820.35) actually exceeded the pre-migration average ($96,321.54), indicating new acquisition continued strong through the window.

• batch migration (Batch 3 completed Feb 24)
• billing date delay of 1-2 months on multi-pack subs

Skio catch-up call (Feb 24) - Elliot reiterates long-term move right; migration reversible

Hardik shared the transcript of a Feb 24 Skio catch-up call into a later Claude session (not stored verbatim). Per the compaction summary, Elliot (Skio) reiterated the long-term move was right; the 'reversible via Skio bulk operations' point is attributed in the summary to Nick (Core Team call), not clearly to Elliot. Distinct content for the Feb 24 Skio call beyond Elliot's general support is not preserved.

• Discussion that the billing-interval migration is reversible via Skio bulk operations

Nuora Core Team Strategy Call (Feb 24) - Nick confronts Hardik over migration done without contrast analysis

Hardik shared the Feb 24 Core Team Strategy Call transcript into a later Claude session. Per the compaction summary: Nick was upset that Hardik ran the bulk migration without first doing the before/after analysis Nick explicitly asked for. Nick's core concern: Nuora spends $80k/day on ads funded by MRR, so reducing MRR breaks the acquisition flywheel. Nick demanded exact numbers, said 'we cannot descale at any point' (payment processors would penalize them), confirmed the change is reversible via bulk operations, told Hardik to use the scientific method / always do contrast analysis, said they cannot sustain ~20k/day MRR, and told Hardik to 'figure it out and speak to Claude. Give this transcript.' Hardik then asked Claude 'am i cooked?'. (Ollie referenced as deliverable audience, not confirmed attendee; 'brand owner' for Nick is external context.)

• Discussion of possibly reversing the migration via Skio bulk operations if revenue impact too severe

"we cannot descale at any point"Nick (paraphrased in summary)

"figure it out and speak to Claude. Give this transcript."Nick (paraphrased in summary)

"bro looking at this, am i cooked? (don't commit anything on github now) let's just have a chat"Hardik

Nuora Subscription Revenue Analysis prepared (Skio MRR / churn / cadence) from 104,525-record SKIO export

Hardik Dewra (CRO) prepared the 'Nuora Subscription Revenue Analysis' on Feb 25, 2026, evaluating the Feb 11-24 migration. Data sources: a SKIO subscription export of 104,525 records (including inactive) plus Shopify analytics. Headline: current MRR $1,785,570.83, annualized $21,426,849.91, 65,212 active subscribers, 36,757 all-time cancelled, 2,554 failed, 35.2% overall churn. Argued quarterly billing retains better on a 30-day basis and that revenue is shifted in time, not lost. Notes SKIO shows current state only, so pre-migration MRR cannot be reconstructed from this file. This doc is the central artifact the migration work feeds into and was later re-loaded as context in Mar 6 and Mar 7 sessions (under path Nuora/README.md).

• revenue analysis
• SKIO subscription export (104,525 records)
• Shopify analytics pull

Quarterly-vs-monthly retention finding documented (quarterly retains best on 30-day)

Early retention analysis found quarterly (3-pack) subscribers churn ~18% less than monthly on a 30-day basis (17.0% vs 19.6%). Total subs ever: Quarterly 45,048 / Bimonthly 20,042 / Monthly 39,433. Month-1 retention: 87.2% / 85.9% / 89.2%. Overall churn: 32.6% / 31.7% / 39.9%. 30-day churn: 17.0% / 20.7% / 19.6%. On 29,474 active quarterly subs, the 2.6pp 30-day difference preserves an estimated ~766 additional subscribers/month. Cautioned this is early data (most subs < 2 months old), needing 90+ day confirmation. The core evidence that consumption-matched billing reduces churn.

MRR-by-cadence and LTV-by-cadence breakdown documented

Current MRR by cadence: Monthly (1-pack) 22,690 subs (34.8%), avg order $39.33, MRR/sub $38.91, total MRR $882,916.66 - highest MRR contributor; Bimonthly (2-pack) 13,048 subs (20.0%), avg $50.06, MRR/sub $25.03, $326,568.67; Quarterly (3-pack) 29,474 subs (45.2%, largest segment), avg $58.64, MRR/sub $19.55, $576,085.50 (lowest MRR/sub because revenue is spread over 3 months). LTV: Monthly Est $69.33 / Proj $198.37 (39.9% churn); Bimonthly Est $73.80 / Proj $121.16 (31.7%); Quarterly Est $86.06 / Proj $114.72 (32.6%). Report notes projected LTV currently favors monthly only because the dataset is young; Estimated LTV (Price x Cycles) already shows quarterly leading ($86.06 vs $69.33).

Cancellation reason breakdown documented (validates migration thesis)

Cancellation analysis of 36,757 all-time cancelled subscriptions. Top reasons: 'I subscribed by accident' 12,191 (33.2%) - #1 by a wide margin, flagged as a checkout UX / subscription opt-in problem and the highest-leverage churn lever independent of billing cadence; 'Unknown/No Reason' 10,259 (27.9%); 'I have too much product' 6,090 (16.6%) - directly validates the consumption-matched billing migration thesis (overstocked customers cancelling); 'It is too expensive' 4,882 (13.3%); 'Product Issue' 1,506 (4.1%); 'Shipping/Delivery Issue' 1,182 (3.2%). Cancellation by cadence: Monthly 15,082 (avg tenure 1.7mo), Quarterly 14,232 (1.0mo), Bimonthly 7,443 (1.2mo).

• cancellation reason analysis

""I subscribed by accident" (33.2%) is the #1 cancel reason by a wide margin. This is a checkout UX problem"Hardik Dewra (report)

Migration activity snapshot and transition-period revenue documented

Migration activity as of the report: 20,831 new subscribers since Feb 11; 44,381 pre-existing subs still active; 7,404 pre-existing subs cancelled since migration. Shopify subscription sales averaged $96,321.54/day in the 30 days pre-migration vs $116,820.35/day during the transition period - transition-period daily revenue EXCEEDED pre-migration, indicating new acquisition was not disrupted. New-acquisition pace ~1,488 new subs/day (20,831 in last 14 days). Brand-scaling context: from ~2,000 new subs/month mid-2025 to 35,000+ in February 2026; most subs < 2 months old, inflating the 35.2% lifetime churn - the 30-day churn rate (17-20%) is more actionable.

• migration impact monitoring
• data interpretation note

180-day revenue projection and monthly revenue ladder documented (the 'revenue wave')

180-day projection (Feb 25 - Aug 24, 2026) on the current 65,212-subscriber base alone (excludes new acquisition, an explicit 'conservative floor'): $10,142,650 cumulative. Period windows: Days 1-30 $972,252 ($31,363/day, 'delayed billing trough'); 31-60 $1,475,105 ($49,170/day); 61-90 $2,380,411 ($79,347/day, 'largest billing wave - delayed 3-packs come due', Apr 27-May 26); 91-120 $1,470,186 ($49,006/day); 121-150 $1,115,762 ($37,192/day); 151-180 $2,728,935 ($90,964/day, 'second full quarterly cycle - revenue normalizes'). Cumulative ladder: 30-Day $972,252; 60-Day $2,447,356; 90-Day $4,827,768; 120-Day $6,297,953; 150-Day $7,413,715; 180-Day $10,142,650. First projected $100k+ revenue day: March 28, 2026. Monthly projection: Mar $994,063; Apr $1,616,745; May $2,289,229 (5 days >$100k); Jun $1,414,812; Jul $1,405,565; Aug $2,306,310 ($96,096/day, 12 days >$100k).

Deleted Claude Code session: Nuora SKIO subscription revenue analysis after the bulk migration

Hardik ran a Claude Code session (later deleted, recovered via subagent transcripts + a compaction summary) to build the subscription revenue analysis after the bulk migration. He provided 4 data files and migration context. Claude read the files, set up a Python venv (/Users/hardikdewra/nuora-analysis-venv/), built an analysis script, and generated a 7-sheet Excel workbook plus a GitHub README. Deliverables pushed to a private GitHub repo 'nuora-subscription-analysis' under HardikDewra. The migration changed billing frequency for multi-pack subscribers to match consumption (3-pack monthly -> quarterly), delaying billing 1-2 months. Errors fixed: pip 'externally-managed-environment' (resolved with the venv); git push rejected (resolved with 'git pull --rebase && git push').

• Claude Code session: read files, built pandas analysis script in venv, generated Excel workbook + GitHub README, pushed to private repo nuora-subscription-analysis

Claude subagent researched the Skio GraphQL API to enable read-only subscription data verification

A Claude subagent (agentId aafa08f93c97aeb14) dispatched at 06:55 UTC to find Skio's API docs (Glob, Bash find, WebSearch, WebFetch). Findings: Skio uses a GraphQL API at https://graphql.skio.com/v1/graphql, header auth 'authorization: API {token}' with 'Content-Type: application/graphql'. Key read queries: Subscriptions, SubscriptionByPk, SubscriptionLines, StorefrontUsers, DailyMetrics. Mutations support swapping product variants, changing billing, applying discounts, pausing/reactivating. platformId maps to Shopify GIDs (e.g. gid://shopify/SubscriptionContract/12346616394). Limits: 2,000 requests/min per token, max depth 4, max 100 nodes per request. Backed Hardik's attempt to verify subscriber counts via a Skio API key.

• Skio GraphQL API documentation research via Claude subagent (Glob, Bash, WebSearch, WebFetch)

Skio read-only API key had no access to subscription data (only theme/selling-plan tables)

Hardik provided a Skio API key (ed99c3e4-9794-4fed-8fb2-2d884628d7fb) for read-only verification. Per the compaction summary, the key only had access to Copies, GroupDiscountPlan, SellingPlanGroupMigration, and Theme2/Themes tables, NOT subscription data. Claude told Hardik he needed broader permissions to pull subscription counts via the API. This blocked direct API-based verification and forced reliance on CSV exports.

• Skio GraphQL API key permission check: failed/insufficient scope (no subscription tables)

Subscriber count discrepancy investigated: first CSV 46K rows / 43,044 active vs Skio dashboard ~68K active

Hardik questioned why the first SKIO CSV export (subscription-export-1771997035010.csv) reported ~46,226 rows (43,044 active, 3,127 cancelled, 54 failed, 1 paused) when the Skio dashboard showed 68,158+ active. Claude confirmed all 4 products WERE in the CSV (Vaginal Probiotic - 100% Real 25,293; Gut Ritual 10,332; Biofilm Probiotic 5,551; Vaginal Probiotic 5,050). The ~25K active gap was unexplained (likely an export row limit or filter). Hardik decided to re-export and remove the confusing 68k/43k scope section from the README.

• CSV vs Skio dashboard reconciliation: subscriber-count discrepancy investigation

Claude subagent ran full analysis on re-exported Skio CSV: 104,533 rows, 65,218 active, $1.79M MRR

A Claude subagent (agentId a96e874c5b0f6d94d) ran a comprehensive pandas analysis at 08:07 UTC on the re-exported Skio CSV (subscription-export-1772003067648.csv) using the venv. Results: 104,533 total rows, 104,163 unique subscriptions. Status: 65,218 ACTIVE, 36,759 CANCELLED, 2,554 FAILED, 2 PAUSED. Total MRR $1,785,580.45 (~$21.4M annualized). Overall churn 35.2%; 30-day churn 42.5% (14,989 cancellations vs ~35,237 base). Since migration (Feb 11+): 20,832 new subs, 44,386 pre-existing active, 8,259 cancelled post-migration. Top cancel reason 'I subscribed by accident' 12,192 (33.2%). The re-export resolved the earlier ~46K vs 68K gap by showing a far larger active base (65,218). Products (all statuses): Vaginal Probiotic - 100% Real 75,033 (41,891 active); Gut Ritual 10,641 (9,329 active); Vaginal Probiotic (legacy) 9,738 (6,859 active); Biofilm Probiotic 9,121 (7,139 active).

• Claude subagent ran pandas analysis script via venv python3 on re-exported Skio CSV

Churn/retention/cancellation/billing breakdowns from the re-exported CSV (subagent output)

From the CSV-analysis subagent. Churn by cadence: Monthly 40.0% (39,119 total | 22,444 active | 15,666 cancelled), Bimonthly 31.7% (20,042 | 13,048 | 6,358), Quarterly 32.6% (45,048 | 29,474 | 14,681). Month-1 retention: Monthly 86.2%, Bimonthly 87.0%, Quarterly 87.2%. Full cancel-reason distribution: 'subscribed by accident' 12,192 (33.2%), 'No reason given' 10,259 (27.9%), 'too much product' 6,091 (16.6%), 'too expensive' 4,882 (13.3%), 'Product Issue' 1,506 (4.1%), 'Shipping/Delivery Issue' 1,182 (3.2%), 'Other' 193 (0.5%), 'no longer use' 173 (0.5%), 'need it sooner' 118 (0.3%), 'splashScreen' 103 (0.3%). Pricing per active cadence: Quarterly 29,474 subs avg $58.64 MRR/sub $19.55 ($1,728,256.49 order value); Monthly 22,444 avg $39.22 ($880,233.75); Bimonthly 13,048 avg $50.06 ($653,137.34). Currency: USD 64,793 subs/$1,764,711.33 MRR (~99.3%), GBP 211, AUD 86, CAD 81, EUR 19, plus tail. Acquisition: 2025-09 308; -10 343; -11 455; -12 9,385; 2026-01 18,791; 2026-02 35,113 (partial). Cycles completed (active): 1 cycle 48,898 (75.0%), 2 cycles 12,669 (19.4%), 3 cycles 2,480 (3.8%); avg cycles Monthly 1.52 / Bimonthly 1.31 / Quarterly 1.27.

Forward next-billing distribution by month (the delayed-billing 'revenue wave' evidence)

The subagent's NEXT BILLING DATE DISTRIBUTION quantifies the delayed-billing revenue wave central to the migration debate: 2026-02 3,073 subs/$115,926.83; 2026-03 21,346 subs/$883,563.65; 2026-04 14,849 subs/$779,720.77; 2026-05 22,337 subs/$1,296,300.49 (big quarterly renewals); 2026-06 1,321 subs/$73,696.80; then a long tail to 2027+. Concrete evidence revenue was shifted, not lost - the core point for Nick.

README/Excel deliverable headline findings (earlier first-CSV numbers, partly superseded)

The compaction summary records the deliverable's headline findings from the FIRST CSV (later partly superseded by the re-export): quarterly churn 26% lower (6.0% vs 8.1%); 180-day cumulative $7.11M; first $100k revenue day projected March 28; quarterly m1 retention 89.7% vs monthly 87.5%. Hardik extended the projection from 90 to 180 days because billing delays pushed many subs past the 90-day window. NOTE: the 89.7/87.5 m1 figures differ from the re-export's 87.2/86.2 - flagged as superseded earlier-deliverable numbers; the published Feb 25 doc used the $10.14M / 65,212-base figures.

Migration left bugged cadences / far-future next-billing dates as data artifacts

The re-exported CSV showed migration data artifacts: subscriptions with implausible billing interval counts (4/5/6/8/10/12/16/24/26/40/44/200 months) and next-billing dates as far out as 2030-08, 2033-10, 2041-03, 2050-09, 2064-10 (each ~1 sub). Flagged as worth cleaning up. Whether cleaned is unknown.

~87 'Skio bulk operation is complete' notifications hit inbox (bulk-op heavy period)

The Mar 4 2026 inbox analysis found 'Your Skio bulk operation is complete' was the single most frequent Primary-inbox subject, appearing 87 times of 304 emails (~28.6%). The Updates tab separately counted 6 of the same plus 5 'Self Serve Bulk Operation Preview Export'. Feb 2026 was the busiest month in the Primary inbox: 109 of 304 emails (35.9%), consistent with the Feb 11-24 migration window. The notifications confirm a high count of completed Skio bulk operations on the Nuora account, but the source does not state which products/variants each touched or how many subscriptions each affected. Individual dates not in source; assigned approximately to the Feb 2026 bulk-op window.

• Many Skio bulk operations run on Nuora (count inferred from 87 completion emails + 6 preview-export emails); specific operation types/targets not captured

Bulk-changes call: Nick's decision rule = pick the path that avoids supplier contact; Hardik proposed a new product

On the 2026-02-27 'bulk changes' call (one of the 2 Skio/bulk-change calls reviewed in the L60D file), Nick set the rule that the correct option for the pending bulk change was whichever path did not require contacting the supplier at that moment. Hardik instead proposed creating an entirely new product and updating the supplier beforehand, counter to Nick's preference. Cited as the earliest 'implementation before safest test' example. No SKU IDs, variant IDs, or subscription counts recorded.

• bulk change (option not requiring supplier contact preferred over creating a new product)

"whatever right now doesn't require contacting supplier... is the right solution."Nick

"what do you think about creating a new product altogether... and will update the supplier beforehand?"Hardik

Cart skip / direct-to-checkout change shipped (end of Feb)

Around end of February (Hardik: 'I was the end of February changed'; Nikita: 'It was like 27th, 28th of February when it was changed') Nuora changed the storefront flow to send customers directly to checkout, skipping the cart. The slide cart that previously increased urgency and trust was removed. Later identified as coinciding with a doubling of cost-per-add-to-cart. Two hero SKUs existed at this point. (This delay/cart-change date also matches the 'billing delay running since 27 Feb' referenced on April 7.)

• direct-to-checkout flow (skip cart) enabled on storefront

"It was like 27th, 28th of February when it was changed. We have two hero SKUs right now at this point."Nikita Lienov

Custom cart brief: replace legacy cart/clear subscription pattern with Cart AJAX selling_plan flow

Hardik (CRO) wrote a technical brief for Tomide (dev) for a custom cart drawer and /cart page (no exact day; approximated to Mar 1). It documents that old Nuora buy boxes used a 'cart/clear -> cart/add -> /checkout' URL pattern for subscriptions, to be replaced. Subscriptions added through the Cart AJAX API with a selling_plan parameter will flow through Shopify checkout normally and create the SKIO subscription on order completion, removing the URL hacks.

• Replace legacy cart/clear -> cart/add -> /checkout subscription URL pattern with Cart AJAX API selling_plan flow

"The old Nuora buy boxes used cart/clear -> cart/add -> /checkout URLs for subscriptions. The new cart module should replace this pattern."Hardik (brief)

Cart brief flags SKIO/Ka-ching SKU mapping issues with quantity logic; recommends hiding qty adjuster

The brief's quantity-upsell section warns against letting a customer order qty 3 of a 1-bottle variant (ships 3 separate bottles, no discount) versus qty 1 of a 3-bottle variant (ships the bundle at discount). Hardik is given a decision: Option A increment quantity with savings messaging, or Option B hide the quantity adjuster and only show bundle-upgrade prompts. The brief recommends Option B as safer given the SKIO/Ka-ching SKU mapping issues Hardik has had with quantity logic. Bundle upsell prompts upgrade from 1-pack to 3-pack ('Switch to 3-Pack & Save 42%', $99/quarter vs $152).

• Quantity adjuster behavior decision (Option A increment vs Option B hide and show bundle upgrade)

"Option B is safer given the SKIO/Ka-ching SKU mapping issues you've had with quantity logic."Hardik (brief)

Cart brief: confirm with Elliot which products are SKIO-only vs still on Ka-ching; selling-plan gotchas

In the SKIO/selling-plan gotchas section, the brief warns not to mix Ka-ching bundles with the cart AJAX API (Ka-ching bundle logic may conflict with direct cart API calls) and instructs the dev to confirm with Elliot which products are fully on SKIO selling plans only. It notes selling plan IDs are per selling plan group, and duplicated products for A/B tests each have their own selling plan group with different IDs. It also documents (Section 4) an OPTIONAL Skio storefront API call to separate billing from delivery cadence: POST https://api.skio.com/storefront-v2-http/get-product-variant-selling-plans with { productVariantPlatformId: gid://shopify/ProductVariant/VARIANT_ID } returns full selling plan groups with billing/delivery intervals ('Billed quarterly, delivered every 90 days'). Section 11 gotcha: multiple cart line items can share the same variant_id when selling plans differ, so cart/change.js must use the unique line item 'key', not variant_id. Section 14 QA: 'No conflicts with Ka-ching on any active product', 'No conflicts with SKIO widget on PDPs', 'Bundle upgrade swaps variant correctly (preserves selling plan)'.

• Confirm with Elliot which products are fully on SKIO selling plans vs still on Ka-ching
• Map correct variant + selling_plan combo per selling plan group for cross-sells
• Use line item key (not variant_id) for cart/change.js
• Optional Skio storefront API get-product-variant-selling-plans to separate billing vs delivery cadence
• QA: no Ka-ching/SKIO widget conflicts; bundle upgrade preserves selling plan on variant swap

"Confirm with Elliot which products are fully on SKIO selling plans only."Hardik (brief)

"Multiple line items can share the same variant_id if they have different selling plans. Always use the unique key property from the cart item."Hardik (brief)

Cart brief subscription display mockups internally inconsistent (30-day/35% vs 90-day/42%)

HANDOVER FLAG: the cart drawer layout (Section 3) renders a subscription line as '3 Bottles / Subscribe & Save - 30 Day / Saves 35% / $99.00 / strikethrough $152.00' and Section 4 display logic also uses 'every 30 Days' / 'Save 35%'; but the Section 9 /cart page example for Feminine Balance Gummies - 3 Bottles uses 'Every 90 Days' / 'Saves 42%'. Same $99/$152 price, but cadence and savings differ between the two mockups. These are mock display values, internally inconsistent, NOT confirmed live Skio plan data.

"plan.name = 'Delivery every 30 Days' or 'Delivery every 90 Days'"Hardik (brief)

Next-actions tracking plan documented: weekly SKIO export + checkpoints (handover-critical forward plan)

The Feb 25 report set a follow-up monitoring plan directly relevant to the Nadia handover: weekly SKIO export + MRR tracking every Monday starting Mar 3 (track actual vs 180-day projection); 30-day retention checkpoint + revenue bridge (actual vs projected) on March 27, 2026; 90-day billing-wave checkpoint on May 26, 2026 (verify the largest delayed-3-pack billing wave ~$79k/day materializes); 6-month cohort LTV comparison on August 25, 2026 (quarterly subs complete 2 full cycles - definitive LTV answer). Also flagged cancel-save flow and checkout UX fix (targeting the 33.2% 'subscribed by accident') as ASAP priorities.

• Weekly SKIO export + MRR tracking (every Monday from Mar 3)
• evaluation plan / monitoring schedule

Fathom recap: Nikita strategy meeting on subscription-only offer to fix low AOV

A Fathom meeting recap email (Tue 03 Mar 2026 13:56:25 UTC, 'Recap of your meeting with Nikita Lienov') was captured in the inbox. The snippet states the meeting purpose was to align on strategic priorities to boost AOV and organic traffic, with a key takeaway to test a subscription-only offer (described as '100% take rate') to fix the current model's low AOV. A strategy decision touching the Nuora subscription model rather than a Skio SKU operation; full recap body and fathom.video link not captured.

"New Strategy: Test a subscription-only offer (100% take rate) to fix the current model's low AOV."Fathom recap (of Nikita meeting)

Elliot (Skio) filed a support ticket to revert some of Nuora's bulk subscription changes

An email captured in the Mar 4 Gmail triage shows Elliot (elliot@skio.com) wrote to Skio Support with subject 'Bulk changes - Nuora' on Wed 04 Mar 2026 12:48:49 UTC. The snippet reads that the previous week the merchant (Nuora) made bulk changes and requested that some of them be reverted, which Skio's team had successfully helped with - a partial rollback of an earlier Nuora bulk operation, naming the store domain 084c8e-de.myshopify.com. Full ticket body beyond the snippet not captured.

• Skio support ticket to revert a subset of an earlier Nuora bulk operation; Skio reported the revert was successfully completed

"Last week the merchant made some bulk changes and they requested that some of them were reverted, which our team successfully helped them"Elliot (elliot@skio.com)

Elliot shared Google Sheet 'Reversing Bulk Operation (Highest PDP Gummies)' - names a product and a reversal op

The Updates-tab subagent surfaced a Google Drive share-request notification: from 'Elliot Mitchell (via Google Sheets)', subject 'Share request for "Reversing Bulk Operation (Highest PDP Gummies)"'. A direct operational artifact: a Google Sheet whose title names (a) a REVERSE/rollback of a bulk operation and (b) a specific Nuora product line, 'Highest PDP Gummies' (the highest-converting gummies SKU family). Corroborates and gives a product target to the Mar 4 'Bulk changes - Nuora' revert ticket. Only the share-request subject was captured; sheet contents, exact date, and which variant/SKU/qty were reversed are not in source. The single most important miss tying 'some bulk changes were reverted' to a named product + reversal workbook.

• Google Sheet 'Reversing Bulk Operation (Highest PDP Gummies)' created/shared by Elliot, indicating a documented rollback of a bulk op on Nuora's 'Highest PDP Gummies' product; only the share-request notification captured

"Share request for "Reversing Bulk Operation (Highest PDP Gummies)""Elliot Mitchell (Google Drive share notification)

Open question raised in Elliot's Google Sheets comment: why change to 3-month variants

The Updates-tab analysis surfaced a Google Sheets comment notification (from Elliot Mitchell, comments-noreply@docs.google.com) on a sheet 'Nuora Optimisations'. The truncated comment subject reads 'Nuora Optimisations - why is this changing to 3 month varia...', indicating Elliot questioned a change to '3 month variant(s)'. Ties to the quantity-based -> 1/2/3-month variant thread. Exact date and full text not captured; assigned to source date as upper bound.

"Nuora Optimisations - why is this changing to 3 month varia..."Elliot Mitchell (Google Sheets comment)

Skio subscription exports and Shopify order exports pulled for Nuora (export-ready notifications)

The inbox analysis counted multiple data-export notifications for Nuora over the Dec 2025-Mar 4 2026 window: 'Your Skio Subscriptions export is ready' 6 times (Primary) + 3 (Updates), and 2 Shopify 'Export of your orders' emails (from 'Nuora (Shopify)' mailer@shopify.com, Updates tab) indicating order-data pulls (plausibly to reconcile subscriptions and post-migration fallout). Repeated subscription/order data exports were requested; the transcript captures only subject lines, not export contents/row counts/dates.

• Repeated Skio Subscriptions exports generated for Nuora
• 2x Shopify 'Export of your orders' generated for the Nuora store

Gmail inbox triage session (3 Claude subagents) quantified the Skio/Nuora email footprint

On Mar 4, a Claude Code session (sessionId bdd8de0d-963d-4538-856c-bdf444124964) ran 3 subagents to analyze Gmail across Updates, Primary, and Promotions tabs from pre-saved gmail_search tool-result JSON files (python3/Bash). An inbox-cleanup task, not a Skio operation, but it quantified the footprint: Primary inbox 304 emails / 26 senders; Skio system sender no-reply@team.skio.com 99 (Primary) + 14 (Updates) = 113; help@skio.com 'Atul from Skio' 4 (Primary) + 1 (Updates, ticket #71792897) = 5; elliot@skio.com 2 (Primary). A separate connection (Hitesh Gupta's Gmail MCP Server, 19 tools) found 'Your Skio bulk operation is complete' 87 times (28.6% of Primary) and total inbox 1,105 emails. The agents ran no Shopify/Skio mutations; they only aggregated email metadata.

• 3 Claude subagents parsed Gmail tool-result JSON with python3 to produce sender/subject/date breakdowns; no Shopify or Skio mutations run

Fathom meeting-recap email volume (potential Skio call records)

The Gmail report counts Fathom at 6 in Primary and 25 in Updates ('Meeting recaps'), ~31 flagged for deletion. Not tied to Skio specifically, so contextual only: if any Skio/Elliot calls were Fathom-recorded, the recaps would hold operation detail. The report itself contains no fathom.video URL.

Skio analysis doc loaded as passive context into Obsidian notes audit (mislabeled README)

On Mar 6 a Claude Code subagent ran an Obsidian-notes-cleanup audit (KEEP/DELETE verdicts) and read /Users/hardikdewra/Documents/Obsidian Vault/Metta/01 - Projects/Nuora/README.md, whose actual content is the full 'Nuora Subscription Revenue Analysis' (the Skio MRR doc: 65,212 active, $1,785,570.83 MRR, $21,426,849.91 annualized, 36,757 cancelled, 35.2% churn). The audit agent never engaged the subscription content; it verdicted KEEP and mislabeled it a 'Navigation hub'. No Skio operations were run. No Elliot/Atul/Kaching/bulk-op/subagent activity.

• Read of Nuora/README.md (= Skio analysis doc) during notes audit

"README.md | Navigation hub with links to Nuora project files, client feedback docs, etc | KEEP | Project management reference"audit agent verdict

Product-data subagent ingests Nuora files incl. the SKIO Subscription Revenue Analysis; documents bundle SKUs

A Claude subagent was spawned to extract all Nuora product data, copy, pricing, ingredients, and specs for Gut Ritual capsule and gummies, for a brand landing homepage + Deodorant PDP build in Paper.design. It ran a find + Read sweep across 6 Nuora files; one (README.md) is the full 'Nuora Subscription Revenue Analysis' (Feb 25, $1,785,570.83 MRR / 65,212 active / 104,525 SKIO records). The subagent ran no Skio operations. The landing plan defined three bundle SKUs: 'Gut + Glow' (Gut Ritual + Vaginal Probiotic) $78.69 (was $99.99, save 21%); 'Total Body' (Gut Ritual + Vaginal Probiotic + Deodorant DUO) $109.99 (was $139.98, save 21%); 'Build Your Own' (any 3+ products) 15% auto-discount. Per-bottle pricing read: Gut Ritual 1 bottle $59, 2-pack $53.10/ea (save 10%), 3-pack $47.20/ea (save 20%); Vaginal Probiotic gummies 1 pack $40.99, 2-pack $36.89/ea (save 10%), 3-pack $34.49/ea (save 15%), 4.8/5 from 7,139+ reviews.

• File read sweep (Bash find + Read) over Nuora project directory; no Skio/Shopify bulk operation executed

"I've done a thorough read of all Nuora project files. Here's everything for Gut Ritual, the gummies product, and related specs"subagent (Claude)

Core team subscription meeting (held day before the Mar 11 call)

Hardik referenced a meeting the team had 'yesterday' (normally Tuesdays, postponed by Nikita), from which he brought meeting notes covering the Skio subscription/variant cleanup reported on the Mar 11 call. The notes drove the discussion of the deleted gummies variant, the ~3K migrated subscribers, the 11 remaining active subscribers, and the ~696 people on old gummies variants. Attendees of this prior meeting are not stated beyond Hardik.

"We used to have meetings on Tuesday, but then you postponed it. So I have all the meeting notes ready."Hardik

Chargeback rate spike attributed to delayed 3PL shipping; credit-limit / fulfillment payment bottleneck

Opening topic. Hardik reported chargeback rates increasing because shipping is delayed so much that customers stop believing the product will arrive and file chargebacks - a possible 'huge needle mover', tied directly to shipping quantity being delayed. Lucky (fulfillment ops) said Nikita is 'yet to make a payment' and is repeatedly raising the need to increase the credit limit so Nikita can pre-pay further upfront. Nikita said he pays the 3PL almost every two days but order surges (e.g. extra 5k orders) outpace payments, creating the appearance of non-payment. ~7k orders pending; Nikita to check WeChat from Lucky and raise the credit limit. Post-migration / ops fallout context (delayed shipping -> chargebacks).

• Check WeChat from Lucky re: credit limit and increase it to clear pending fulfillment (Nikita); pay 3PL to reduce shipping delay driving chargebacks

"chargeback rates might be directly correlated with the shipping quantity, which is getting delayed right now"Hardik

Hardik reports bulk migration of ~3K active subscribers off deleted gummies variant (done with Elliot)

Hardik reported the old highest-generating gummies product had a single product variant (now deleted) that carried pack-quantity options (1/2/3-pack) rather than separate variants per pack. That deleted variant still had ~3K active subscribers whose payments were showing failed repeatedly. With Elliot (Skio), Hardik bulk-migrated these ~3K active subscribers to the correct cadence on the new variant structure, so they are billed correctly again instead of failing. Cancelled subscribers from the deleted variant were also moved (so if they restart they will be on the new structure). Hardik noted Skio's forecast now shows much higher projected cancellations because the cancelled subscribers were pulled in; Nikita said the forecast does not matter since stats only count currently active subscribers. Number groups Hardik recited (5612 who set qty 1 incl. cancelled, 4238 set qty 2, 11162 a further group, ~21K total previously across the variant) are partly garbled by voice-to-text; exact mapping of each number to a quantity is uncertain.

• Skio bulk migration of ~3K active subscribers from deleted gummies variant to correct cadence/new variant (run by Hardik with Elliot from Skio); cancelled subscribers also moved

"this variant was deleted for some reason... and this still had Active Subscribers, which are around 3k... I migrated with the help of Elliot, I bulk migrated it to correct cadence in the new subscriber and they are now getting billed again."Hardik

"It previously was showing failed, failed, failed, failed payment. And now it is showing correctly that they are getting billed."Hardik

Decision on remaining 11 active subscribers in deleted variant (qty 6/9/4)

Hardik flagged 11 people remaining inside the deleted gummies variant with active subscriptions at product quantities 6, 9, or 4 - legitimate higher-quantity opt-ins, not fraud. He asked whether to move them to their chosen quantity. Nikita decided to leave their price, cadence, and quantity exactly as-is so the customer experiences no change, while moving them on the backend. Fathom action item: migrate the 11 active subscribers from the deleted variant to correct variants keeping price/cadence.

• Planned migration of 11 active subscribers from deleted variant to correct variant preserving price/cadence/quantity

"if they are on six, like whatever they have, whatever the price they pay, whatever cadence they have, you just make it seem like they don't even feel anything... for them, nothing has changed."Nikita

Plan to migrate ~696 quantity-inflated subscribers off old gummies variants to new product variant ID via CSV

Hardik described the old highest-gummies product ID with variant 1/2/3. Some customers on variant 1 deliberately increased quantity to 4 or 5; some on variant 3 were at quantities like 396/696. He cited 696 people who deliberately increased quantity. He wants to move them to the newer product variant ID so the old product can be deleted on Shopify, but worried it would be manual one-by-one work. Nikita advised against changing what customers experience (keep price/cadence/quantity) and suggested a CSV download with formulas to remap them to the appropriate variant, submitted to Skio support, rather than clicking through the interface manually.

• Planned remap/migration of ~696 subscribers from old gummies variants to new product variant ID via CSV (formulas) submitted to support; goal to delete old product on Shopify

"you just CSV download with formulas, boom, boom, boom, just change whatever... You submit it to support... you don't need to do manually subscriber."Nikita

"we want to move them to the newer product variant ID, the newer one. This is the old one. So we want to delete it on the Shopify end, the old one."Hardik

Hardik corrects AI hallucination about 28-day billing cycle

Explaining the peaks-and-valleys subscription revenue pattern, Hardik initially attributed valleys to a 28-day billing cycle that came from an AI response. Nikita rejected this, stating Nuora never had a 28-day billing cycle and that the AI gave a response without context. Hardik conceded the other reasons made sense: cancellation spikes just after billing dates, the bulk migration, and failed payments followed by retries. Shows the AI/Claude-sourced billing-cadence claim was unverified and wrong.

"we never had 28 day billing cycle. Never... It says skill likely bills on a 28 day. Bro, who the f**k talks? It is us."Nikita

"you can never trust AI. AI doesn't know any information actually."Nikita

Strategic decision: double down on gut capsules, phase out gummies (gummies to upsell only)

Major product-strategy decision affecting the gummies SKU future. Because gut capsules have far better unit economics, margin, perceived value, and faster production (~1 week for capsules vs ~1 month for gummies), the team agreed to double down on capsules, develop new unique capsule/fiber products, and sell out / phase out gummies over the long run - keeping gummies only as an upsell, not an ads-driven standalone. Nikita to speak to the supplier; large existing gummies stock makes the switchover gradual and 'smooth/safe'. Margin floor 70-75% minimum, striving for ~90%. Strategic backdrop for why the gummies subscription/variant cleanup matters and why gummies pricing was doubled for quarterly billing.

• Planned gradual switchover from gummies to capsules; develop new capsule/fiber SKUs; sell out existing gummies stock; gummies repositioned as upsell

"the data tells us that we should double down on capsules"Nikita

"the only reason I would sell gummies in the long run... I would sell gummies, but not on ads. As an upsell."Nikita

Kaching Bundle pre-tick discount stopped; subscription A/B test via non-clickable element (later judged non-viable)

During the offer-test discussion, Ollie referenced testing a Kaching Bundle pre-tick customers couldn't untick. Hardik confirmed they stopped the Kaching Bundle approach and instead made the subscription tick non-clickable. Nikita and Ollie pushed back that an unticketable checkbox is a non-viable, black-hat-feeling test giving a frustrating false 'out'. The proper approach (per Resilia, Rise Superfoods, Gruntz examples) is subscription as an information banner or options where one-time exists but doesn't make sense, with disclosure ('refill ships every 30 days, cancel anytime'). Takeaway: do not disguise a non-interactive element as interactive.

• Stopped Kaching Bundle pre-tick discount approach on PDP; switched subscription test to non-clickable checkbox (later judged non-viable)

"Kaching Bundle pre-tick that you can't untick."Ollie

"no, we stopped the Kaching Bundle things. We just made sure that the tick isn't clickable."Hardik

Gummies quarterly-billing pricing tests reviewed (double pricing, new design, new pricing)

Hardik reviewed gummies offer tests in Elevate. Because gummies now ship every three months instead of monthly, the team doubled prices to offset AOV drop and tested: variation 1 = double pricing only; variation 2 = new design with double pricing; variation 3 = new design with new pricing. The new-design/new-pricing variant showed ~2.2% conversion with better AOV than control but did not convert well. Pricing shown included three-pack $39.99/mo and $69.99/mo (double-pricing new design) and $54.99/mo, $39.99/mo, $69.99/mo plus a one-time price (read as '$233' - garbled transcription of a one-time purchase price, not an actual per-day figure). Nikita called the double-pricing implementation 'scary' and lacking per-day/per-unit value framing. Connects gummies quarterly billing to pricing strategy.

"we need to double the pricing because the AOV decreases massively because we are shipping them every three months instead of every one month."Hardik

Request to add SKIO Nuora Slack to main Nuora org

Hardik asked Nikita to add the 'SKIO Nuora' Slack to the main Nuora organization of Slack, saying he couldn't add it himself and would forward Nikita the email/invite. Fathom action item: forward the Skio Nuora Slack invite to Nikita for Nikita to add. Relates to ongoing Skio account-management coordination channel.

• Forward Skio Nuora Slack invite to Nikita; Nikita to add it to main Nuora Slack org

"I want to add the SKIO Nuora. Can you add SKIO Nuora to the main Nuora organization of Splek? I am not able to add it. I'll just forward you the email right now."Hardik

Claude/Codex AI usage across ops: David Claude bot, ad mass-analysis/renaming, Codex landing-page automation

Multiple AI-agent usages relevant to ops automation. (1) Hardik wanted a 'Claude bot' with Skio + Shopify access for offers; Nikita explained the powerful 'David Claude' bot is locked to reply only to Nikita because it has 'full power' (could be told to delete everything). (2) Nikita can 'launch a mass analysis from Claude' to rename all ads at once (naming conventions to differentiate capsule vs gummies ad performance). (3) The 28-day-billing claim Hardik repeated came from an AI response and was wrong. (4) Nikita built a Codex (GPT 5.4) system that auto-generates advertorial/listicle landing pages and split tests directly to Shopify, plus Reddit automation accounts (valued ~$10,000-$15,000 saved). Shows AI/agents used to run and analyze operations.

• David Claude bot (Skio + Shopify access, locked to Nikita); Claude mass-analysis to bulk-rename ads; Codex GPT 5.4 auto-builds advertorials/listicles + A/B tests to Shopify; Reddit shill-account automation

"David Claude is like, I intentionally made it so he can only reply to me... you can say to David Claude, hey, delete everything and he'll delete my computer"Nikita

"I can just like, you know, launch a mass analysis from Claude, Claude can just rename the ads, all of them"Nikita

Replo alt-text bug surfaces 'Advertisement for Nuora feminine garments' in Google SERP

Inspecting the Nuora Google SERP, Nikita and Hardik found a product result showing alt-text 'Advertisement for Nuora feminine garments' (and a garbled variant) for the Feminine Balance gummies. Hardik confirmed it's pulled from the alternative text in Replo source code and agreed to fix it. Fathom action item logged. A live storefront/SEO data-integrity issue.

• Fix Replo alternative-text on Feminine Balance gummies image so SERP stops showing 'Advertisement for Nuora feminine garments'

"It's in our source code, bro... It's in Replo... it pulls up the alternative text from Replo and it says Advertising for Nuora"Hardik

Core-team call: Nick mandates A/B test system with before/after screenshots

Nick told Hardik to never run an A/B test again without a system, requiring 'screenshot before, screenshot after.' Sets the experiment-record standard later applied to variant/CRO testing. Separately on this call Hardik said he'd asked Lucky for a quote; Ollie said there was no point waiting for a quote back and Nick asked why he didn't just do the pricing.

• A/B test record system requirement: screenshot before / screenshot after

"Never... do an A-B test again without... system"Nick

"There's no point in waiting for a quote back"Ollie

Gut Capsule Subscription Anomaly Audit - Kaching-to-Skio migration issues found

Per the nuora-timeline.html work log (logged under Mar 17, within a Mar 15-Apr 3 timeline so date approx), Hardik ran a Gut Capsule Subscription Anomaly Audit and found issues with the Kaching Bundle to Skio migration: customers stuck on wrong variants/pricing. All anomalies documented.

• Kaching Bundle to Skio migration anomaly audit
• variant/pricing mismatch documentation

"Found issues with Kaching Bundle to Skio migration - customers stuck on wrong variants/pricing. Documented all anomalies."nuora-timeline.html

Hardik briefs Nikita on Gut Capsule variant/SKU collision and ~$300K shipping risk

Hardik explained the Gut Capsule was previously sold quantity-based (3 quantity = 3 bottles shipped) and is now switched to one variant per pack (one variant for 3 bottles, one for 2 bottles, etc). Because the same single SKU now maps to two different product types, the supplier was getting confused. Legacy subscribers (from before the Kaching Bundles setup) risk being charged/shipped 9 bottles instead of 3 (quantity 3 x per-variant bottle count). Hardik wasn't sure anyone had received 9 bottles yet, but they will be charged if not fixed ASAP. Over $300,000 was at risk; the issue was caught before mis-shipments could scale.

• bulk CSV export of all Skio data
• Claude audit of exported CSV
• supplier logic gate
• master product spreadsheet in ClickUp
• GitHub repository
• Slack message to Elliot

"the gut capsule, which previously we were selling as three quantity means three bottles... now we have switched over to one variant for each of them, like one variant for three bottles, one variant for two bottles"Hardik Dewra

"because of this, we have over $300,000 at risk. Yeah, this is lucky, lucky, yeah, lucky should have been mindful."Nikita Lienov

Hardik ran Claude audit on bulk-exported Skio CSV to get affected subscriber counts

Hardik bulk-exported all Skio subscription data into a CSV, loaded it into Claude, asked for an audit, and got exact affected-subscriber numbers: ~5,854 people with quantity more than one, and 9,379 people on the new variant-based subscriptions. He told Elliot (Skio) the situation needs fixing ASAP. Planned fix: filter people with quantity 2 or 3 (new variant type only has quantity one), swap the product variant, and reduce the quantity. (Note: a separate same-day source states the Gut Capsule export was 21,280 rows / 20,788 unique subscriptions; the call transcript itself gives no row count.)

• Skio bulk CSV export
• Claude audit of CSV
• planned Skio variant swap + quantity reduction

"I have bulk exported all the SCIO data into a CSV file and I put that CSV file into Claude and after having put that into Claude, I have asked it for the audit and I ran through the audit and I came up with the exact numbers"Hardik Dewra

"we will be filtering out people who have quantities 2 or 3 because in the new variant type subscriptions, we don't have variant 2 or 3, we only have one and we will just be swapping the product variant and we will be reducing the quantity"Hardik Dewra

Hardik texted Elliot on Slack to fix the Gut Capsule variant issue ASAP; built supplier logic gate

Hardik had already texted Elliot on Slack about the Gut Capsule variant/quantity problem, and gave the supplier the GitHub repository and a logic gate so they would not multiply quantity by bottle count. The supplier logic gate: quantity 3 ships only 3 bottles (not 9), quantity 2 ships 2 bottles (not 4); if quantity is 1 they must check whether it is the legacy variant or the new variant before shipping. Hardik called it a non-ideal interim situation and said he had updated the supplier already.

• Slack message to Elliot
• supplier logic gate
• GitHub repository handed to supplier
• master product spreadsheet in ClickUp

"I have already texted Elliot regarding this on Slack."Hardik Dewra

Hardik built a Nuora master product spreadsheet (product/variant IDs, cadence, qty) in ClickUp

To fix the SKU confusion, Hardik created a separate Nuora master product sheet listing all products with product IDs, variant IDs, ideal cadence, and quantity shown in cart, stored in ClickUp under the resource section. For Gut Capsules the sheet shows quantity-shown-in-cart of 1 (correct for new customers but not for legacy pre-Kaching subscribers who would be shipped multiple bottles). No specific IDs were spoken aloud on the call.

• master product spreadsheet in ClickUp listing product IDs, variant IDs, ideal cadence, quantity shown in cart

"I made a separate Nora master product sheet, which has a list of all the products... product IDs, variant IDs, ideal cadence, quantity shown in cart"Hardik Dewra

Gummies confirmed unaffected by the variant/SKU issue

Hardik confirmed to Nikita that the variant/quantity problem does not exist with the gummies; gummies are totally fine. Nikita confirmed this was lucky given the capsule case carried over $300K of risk. (Transcript says only 'gummies are totally fine'; does not specify Feminine Balance or any gummy product name.)

"you don't have the same problem with gummies, right? Yeah, gummies are totally fine."Hardik Dewra

Hardik's verbal four-item summary of the Gut Capsule fix package

Hardik gave a compact spoken recap of the full fix package for the Gut Capsule subscription problem: '(1) Subscription from Kaching, (2) supplier alignment, (3) master product spreadsheet, (4) github repository, logic gate - have given them the github repository thing and texted Elliot of fixing - and the new offers.' The cleanest single enumeration of the artifacts/actions, useful as the handover checklist for Nadia.

• Kaching subscription context
• supplier alignment
• master product spreadsheet
• GitHub repository
• logic gate
• Slack message to Elliot

"Subscription from Kaching, supplier alignment, master product spreadsheet, github repository, logic gate, have given them the github repository thing and texted Elliot['s] key of fixing and the new offers."Hardik Dewra

Hardik built a Claude-powered 'Nuora Offer Engine' GitHub repo; Nikita mandates Python scripts + JSON/Postgres

Hardik built a GitHub repo called the Nuora Offer Engine: he feeds it failed offer tests (screenshots + written reasoning), it extracts learnings, uploads to GitHub, and recommends what tests to run and what offer pricing/stack to use to raise AOV/CVR without being assumption-based. It also benchmarks Nuora offers against competitor stacks he feeds it ('the OMRE one, the ANKWAE one'). Nikita pushed back: AI hallucinates large amounts of data and hallucinates assumptions if not given methodology; never trust AI with large data unless it uses Python scripts for surgical precision; use JSON trackers or a Postgres database (not MD files) for A/B-test/offer intelligence (MD fine for proven principles). Nikita named models in the warning: 'Claude Opus 4.6, even GPT 5.4... they love to hallucinate large amounts of data', with a concrete failure example (AI returning a 3-ROAS ad that only spent $10 if not given methodology). Hardik said he'd already taken the Python-scripts recommendation into account.

• Claude-built Nuora Offer Engine GitHub repository
• markdown files of past offer tests
• Offer Engine benchmarking vs competitor stacks (Omre, Ankwae)
• recommended Python scripts / JSON trackers / Postgres database

"you cannot trust AI with large amounts of data. Never. Unless it uses scripts... AI must use scripts, like Python scripts... when it comes to analyzing big chunks of data."Nikita Lienov

"in A-B test intelligence for the offer intelligence, use JSON files, JSON trackers, or use Postgres database."Nikita Lienov

Gut Capsule / Gut Reset Kit offer/pricing tests reviewed (best AOV $104)

Hardik walked Ollie through offer tests. (1) Gut Capsule single-bottle offer: control $49 (1 bottle), tested at $59.99 with a free branded storage jar ($10 above control; previously $20 higher, which crushed performance). (2) Gut Reset Kit B: previously $69.99, now $59.99; pricing tiers $99.99 one-time / $64.99 (anchor/recurring) / $39.99 per month (= $119.99 every three months recurring); hit AOV $104, best of all offers. Gut Capsule A (branded jar + free gut item) and Gut Capsule B were 'very bad'. Ollie cautioned they need way more data and not to roll with it on just 3-4% CVR.

• offer/pricing A/B test in offer tester (Elevate)

"$99.99 for one-timer and the $64.99 was a recurring one and below that the $39.99 per month, which translates to $119.99 for every three months that is recurring."Hardik Dewra

Hardik asks Claude to analyze Skio Gut Ritual subscription export for anomalies (capture variant/quantity fallout)

Hardik uploaded a Skio bulk subscription export filtered to the Gut capsule (Gut Ritual) and asked Claude to find anything anomalous to fix, instructing that any flagged pricing must be checked in dollars (subscriptions span other currencies) and Claude must filter currencies correctly. He then scoped the over-ship fallout: count how many subscribers are on '3 quantities AND 3 bottles' (would get 9 bottles) and how many on '2 bottles AND 2 quantities' (4 bottles). Reasoning: Nuora moved off Kaching ('catching') Bundles to the variant structure; new subscribers come in on the new 1/2/3-bottle variants while older subscribers are still on the quantity model, risking supplier over-ship - flagged as a potential 'fuck up' at fulfillment. He asked Claude to write the analysis to a markdown file with context.

• Skio subscription CSV export analysis (Gut capsule filter)
• currency filtering check on flagged pricing
• quantity x bottle-count cross-tab analysis
• Kaching Bundles -> Skio variant migration impact analysis

"we moved away from the catching bundles and moved to the variant stuff... The new people who are coming are on variant, while the older people are on the quantity. Will that make a difference, and will that be a fuck up?"Hardik

Hardik explains Skio selling-plan checkout flow change from Kaching Bundles; drafts Slack/dev/supplier messages

Hardik described the platform change to Claude: Nuora now uses Skio, with Skio selling plan links embedded directly into the front end of the product page. Clicking Add to Cart now goes straight to checkout, skipping the cart page; previously with Kaching ('Catching') Bundle items went into the cart first. He asked Claude to draft (a) a Skio support Slack message to Elliot - explicitly mentioning gut capsules so Elliot doesn't confuse them with gummies; (b) a developer message in his writing style; (c) a supplier message; and he confirmed he had written everything to Lucky (fulfillment ops) - the Lucky message body is a pasted-text placeholder not preserved in the archive.

• Skio selling plan links embedded on front end; Add to Cart routes direct to checkout (skips cart)
• draft Skio support Slack message to Elliot
• draft developer message
• draft supplier message
• sent fulfillment message to Lucky

"Skio selling plans links are directly embedded into the front end of our page. Whenever someone clicks on Add to Cart, it directly takes them to the checkout page, skipping the cart page."Hardik

"just make sure to mention gut capsules, so he doesn't get confused between the gut capsule and gummmies, this is primarily gut capsules"Hardik

Hardik builds a 'logic gate' GitHub repo for fulfillment with Gut capsule product/variant IDs

Hardik asked Claude to turn the analysis into a GitHub repository and push it, restyling the 'logic gate' he built using Haffer ('Heifer') font (locally installed) plus Geist/Inter, light mode, Nuora brand rose color 9B083E used for Gut capsules. He uploaded the NUORA MASTER PRODUCTS SHEET CSV and stated the Gut capsule product ID is 8400072802444, the 3-bottle variant ID 45566109089932, the 2-bottle 45566109057164, and the 1-bottle 45566109024396. The GitHub Pages live page returned a 404 (he had waited a long time); he asked Claude to publish/release the github.io live link and write a README plus a warm message in his style to send to Lucky and team, framing the logic gate as something they might feed into their fulfillment software.

• create GitHub repository and push
• restyle 'logic gate' visualization (Haffer/Geist/Inter, light mode, brand color 9B083E)
• upload NUORA MASTER PRODUCTS SHEET CSV
• publish GitHub Pages (github.io) live link (404 reported)
• write README
• draft warm message to Lucky and team

Bulk export of all Gut Capsule Skio subscriptions and Claude full-dataset anomaly analysis

Hardik bulk-exported the entire Gut Capsule subscription dataset from Skio on Mar 17. The CSV contained 21,280 rows covering 20,788 unique subscriptions (15,609 active / 5,415 cancelled / 239 failed / 17 paused). Fed to Claude to find anomalies, patterns to fix, and actionable insights. Data range late Jan 2026 to mid Mar 2026 (~7 weeks). 99.94% USD, 99.97% US customers, 99.97% free shipping. Product split in export: Gut Ritual 20,795 rows, Vaginal Probiotic 436, Biofilm Probiotic 39.

• Skio bulk export (CSV, 21,280 rows)
• Claude full-dataset anomaly analysis

Anomaly: 50% of cancellations are 'subscribed by accident' (broken checkout flow)

Of 5,312 cancellations, 2,654 (50%) cited 'I subscribed by accident' - flagged as a broken checkout flow rather than a true cancel reason. 588 cancelled within 1 day, 1,023 within 7 days, average time to cancel 16 days, 1,713 had completed only 1 billing cycle. Conclusion: subscription is being auto-opted-in during checkout or the recurring-billing signup isn't clear enough.

Anomaly: customers gaming billing intervals via customer portal (up to 999 months)

Several customers modified their billing interval to extreme values via the Skio customer portal to avoid being charged while keeping the subscription technically active: 999 months (~83 years), 800 (~67yr), 365 (~30yr), 134 (~11yr), 99 (~8yr), 30 (~2.5yr), all now cancelled; a few extreme intervals (11, 9, 8 months) remain active. Other non-standard intervals: 4 WEEK, 5 WEEK, 10 WEEK, 4 DAY, 90 DAY instead of standard MONTH-based. One customer had a 4 DAY interval on a $69 subscription (charged every 4 days, cancelled 'subscribed by accident' - flagged as a system bug); another a 90 DAY interval, still active, 2 cycles completed. Recommendation: cap interval edits to max 3-6 months.

Anomaly: genuinely anomalous USD price of $16.94/bottle; inconsistent same-variant pricing

After confirming international 'extreme' prices were just local presentment currencies (THB 1,634.26, BWP 691.42, HKD 397.80, all ~$51 USD), the one genuinely anomalous USD price was a 1 Bottle, qty 2 subscription at $16.94 USD with no discount, status ACTIVE (normal 1-bottle $49) - investigate as manual override or bug. Inconsistent USD pricing for the same variant with no discount: 1 Bottle qty1 $49.00 (1,195), $50.15 (643), $48.97 (623), $44.10 (4); 2 Bottles qty1 $59.00 (2,303), $53.10 (8), $50.15 (5); 3 Bottles qty1 $69.00 (5,545), $51.51 (17), $50.15 (16), $62.10 (5), $51.54 (3), $51.53 (2). $50.15/$51.51 appear in discounted rows too, suggesting discounts weren't recorded in the Skio export.

Anomaly: terrible first-cycle retention (21% churn before cycle 2)

Of 20,788 subscriptions, 16,234 on cycle 1 (78%), 4,552 on cycle 2 (22%), only 2 on cycle 3. Within cycle 1 alone, 3,184 had already cancelled and 232 failed - 21% churn before reaching cycle 2. Data was only ~7 weeks old so many cycle-1 subs hadn't reached second billing; real churn likely higher.

Anomaly: California Compliance cancellations hitting wrong states; splashScreen UI-bug cancel reason

471 'California Compliance' auto-cancellations found, but only 386 were from California - 84 from Colorado, 1 from Ohio (85 potentially wrongful, costing revenue): either misconfigured compliance rules for CO/OH, or CA-billing customers shipping elsewhere. Separately, 149 entries had 'splashScreen' as the cancel reason - a UI bug leaking internal component names as user-facing data; 132 were 'saved by skip' (retained), but 17 were auto-cancelled by California Compliance with this buggy reason (cancellation-reasons table lists splashScreen at 27 / 0.5%).

Anomaly: expired payment methods on active subscriptions; international non-USD subs

29 active subscriptions already had expired payment methods, 188 more expiring March-April 2026 - involuntary churn waiting to happen; action: send payment-update emails before next billing. Separately, 12 non-USD subscription rows from 10 international customers (GBP, EUR, AUD, BWP, HKD, CAD, THB) in local presentment currencies converting to normal USD equivalents (nothing fraudulent): Botswana, Thailand, France, Germany, UK x3, Australia (active), Hong Kong, Canada (cancelled); 8 active. If Nuora ships domestically only, these will generate failed charges and complaints. Customer emails redacted per PII rule.

Gut anomaly: cancellation breakdown, flow outcomes, timing, quick stats

Of all 5,312 cancellations: 'subscribed by accident' 2,654 (50.0%), Shipping/Delivery 884 (16.6%), 'too expensive' 680 (12.8%), 'too much product' 468 (8.8%), Product Issue 205 (3.9%), splashScreen 27 (0.5%), 'want to order earlier' 6 (0.1%). Cancel flow outcomes: Cancelled 4,416; Cancelled by California Compliance 471; Saved by skip 137; Cancelled by merchant 120; Saved by discount 71; Saved by contact support 21; Saved by delay 12; Saved by discount + edit frequency 8; Saved by edit frequency 3. Timing: within 1 day 778 (14.4%), 7 days 1,482 (27.4%), 14 days 2,120 (39.2%), 30 days 4,836 (89.3%). Quick stats: overall cancellation rate 25.6%; most popular variant 3 Bottles (59%); most popular billing cycle Every 3 months (44%); top payment ShopPay (64%); top state Texas (8.6%); 239 failed/dunning (355 rows in dunning). Variant distribution: 3 Bottles 12,454 (59%), 2 Bottles 5,677 (27%), 1 Bottle 2,664 (13%). Billing frequency: Every 3 months 9,321 (44%), Every 1 month 7,843 (37%), Every 2 months 3,992 (19%). Discount codes (454 rows): WCSMSL20 (167), WELCOME10 (139), WELCOME15 (76), GUTLOVE15 (67). Top 10 states: Texas 1,825, California 1,669, Florida 1,372, Pennsylvania 854, New York 807, Ohio 805, Michigan 784, Illinois 771, North Carolina 705, Washington 689. Weekly creation: 2025-W52 (2), 2026-W02 (3), W03 (301), W04 (1,336), W05 (3,114), W06 (2,464), W07 (2,253), W08 (3,493), W09 (3,380), W10 (3,756), W11 (1,178).

Eight priority action items defined from the Gut anomaly analysis

Eight priority actions: (1) fix checkout flow given 50% accidental subscriptions; (2) cap billing-interval edits in the Skio portal to max 3-6 months; (3) investigate the $16.94/bottle order; (4) send payment-update emails to 29 expired + 188 expiring-soon cards; (5) fix California Compliance logic for 84 CO + 1 OH customers; (6) fix the splashScreen cancel-flow bug; (7) decide on the 8 active international subscriptions; (8) audit USD pricing consistency since $50.15/$51.51 'no discount' rows suggest discount data isn't recorded properly in Skio.

Gut Capsule Logic Gate built for Lucky's fulfillment team (Vercel-deployed)

Per the timeline log, Hardik built the Gut Capsule Logic Gate: a visual decision tree for Lucky's fulfillment team mapping quantity ordered -> variant -> correct fulfillment action. Built as HTML/CSS/JS with Nuora brand colors, deployed at nuora-gut-capsule-logic-gate.vercel.app (and hardikdewra.github.io/nuora-gut-capsule-logic-gate). Addresses the quantity-shown-in-cart vs quantity-sent mismatch so fulfillment ships the correct number of bottles per variant.

• Built Gut Capsule Logic Gate decision tree (HTML/CSS/JS)
• fulfillment variant-to-quantity mapping

"Built visual decision tree for Lucky's fulfillment team. Maps: quantity ordered -> variant -> correct fulfillment action."nuora-timeline.html

Drafted message to Elliot (Skio) re: selling plans skipping cart page

Per the timeline log, Hardik drafted a message to Elliot (Skio) about selling plans skipping the cart page and going directly to checkout. Logged under 'Skio Support - Gut Capsule Issues' on Mar 17.

• Drafted Skio support message re: selling plans bypassing cart

"Drafted message to Elliot (Skio) about selling plans skipping cart page and going directly to checkout."nuora-timeline.html

Core-team call: Nick redirects from markdown to structured data storage

On the Mar 17 core-team call, Hardik presented the offer engine; Nick redirected him from markdown-only storage toward structured data: 'Use JSON files, JSON trackers, or use Postgres database.' Relevant to how variant/test/offer records should be stored.

• Storage decision: JSON files/trackers or Postgres instead of markdown for offer engine records

"Use JSON files, JSON trackers, or use Postgres database."Nick

Skio meeting prep - bulk-op CSVs segmenting gummies subscribers

Per the timeline log, on Mar 18 Hardik created CSV files segmenting gummies subscribers into groups of 50, 109, 878, and 1,220 people in preparation for an Elliot meeting (Skio bulk operations).

• Created bulk-op CSV files segmenting gummies subscribers

"Created CSV files segmenting gummies subscribers: 50, 109, 878, and 1,220 people. Prepared for Elliot meeting."nuora-timeline.html

Skio Catch-up (72 min) - full migration strategy meeting with Elliot

Per the timeline log, on Mar 18 a 72-minute Skio Catch-up / full migration strategy meeting was held with Elliot. Covered product IDs, variant mapping, and discount code cleanup, cross-referenced against WhatsApp history. A follow-up Product ID Documentation task ensured all subscription data references include product IDs (not just names) to avoid team confusion. (Hardik separately told Claude that day he had a meeting with Elliot in 15 minutes and asked which bulk operations to run.)

• Migration strategy meeting (product IDs, variant mapping, discount cleanup)
• Product ID documentation
• plan Skio bulk operations to run with Elliot in the meeting

"Full migration strategy meeting with Elliot. Covered product IDs, variant mapping, discount code cleanup. Cross-referenced WhatsApp history."nuora-timeline.html

"okay so i have a meeting with elliot in 15 mins, tell me what bulk operations to run with him on meeting and what else needs to be done"Hardik

Compare-at Price Redesign (Offer Engine) - 3-pack tier rework

Distinct Offer-Engine pricing-tier item (separate from the Skio halving op). Per the timeline log, Mar 21, tag Offer Engine: 'Compare-at Price Redesign Reworked 3-pack pricing tiers. Original $149 vs $175 felt weak. Redesigned with 66% perceived value markup for 1-pack.'

• Compare-at price redesign of 3-pack pricing tiers

Skio meeting with Elliot (37 min) - discount code removal process

Per the timeline log, on Mar 23 Hardik held a 37-minute Skio meeting with Elliot covering the discount code removal process. A revised CSV with specific discount names was produced. Agreed strategy: remove manual discounts first, then apply fixed price discounts.

• Skio discount code removal meeting
• Revised discount-name CSV

"Discount code removal process. Revised CSV with specific discount names. Strategy: remove manual discounts first, then apply fixed price discounts."nuora-timeline.html

Hardik scopes custom cart drawer + /cart page for Nuora; Skio subscription flow documented; over-shipping history flagged

In a Claude chat, Hardik asked how to build custom checkout carts for Nuora and confirmed he wants both a cart drawer (slide-out) and a custom /cart page, built as custom code (Replo/Liquid/JS) by Tomide, focused on AOV. Claude restated Nuora's existing setup: Skio direct-to-checkout URLs for subscriptions (cart/clear then cart/add with selling_plan then /checkout), Replo PDP pages, AfterSell post-purchase cross-sells, custom buy box components. The cart drawer was specced to use Shopify's Cart AJAX API and show Skio subscription line-item details (selling plan name, billing cadence, savings %). Hardik selected all four AOV tactics: (1) cross-sell complementary product - a gummies buyer sees capsules; (2) free shipping threshold bar; (3) quantity upsell; (4) bundle upsell (upgrade to 3-pack). Claude referenced Hardik's history with Ka-ching/SKIO SKU mapping conflicts where qty 3 of a 1-bottle variant caused over-shipping, and recommended hiding the cart qty adjuster + bundle-upgrade prompts (Option B) so a 1-bottle buyer is prompted to switch to the 3-bottle variant. AfterSell post-purchase already offers capsules at $29.99 (downsell $24.99); Claude suggested a higher in-cart price (~$34.99) or skipping the in-cart capsule cross-sell to preserve the post-purchase offer. Claude created the brief at /mnt/user-data/outputs/nuora-custom-cart-brief.md ending with 6 open questions (#3 = quantity-adjuster behavior). No live store change executed. Products in this source are unnamed 'capsules'/'gummies' + generic 1-bottle/3-bottle variants - no product/SKU/variant/selling-plan ID appears.

• Scoped custom cart drawer + /cart page (no live operation run)
• Specced 4 AOV cart tactics + SKIO subscription line-item display
• Recommendation: hide cart qty adjuster, use bundle-upgrade prompts to prevent qty-3-of-1-bottle over-shipping
• Created technical brief markdown nuora-custom-cart-brief.md (6 open questions)

"Given your history with Ka-ching/SKIO SKU mapping conflicts where qty 3 of a 1-bottle variant caused over-shipping, I'd strongly recommend hiding the qty adjuster and only showing bundle upgrade prompts"Claude

"The 6 open questions at the bottom are important - especially #3 (quantity adjuster behavior)"Claude

Cart / skip-checkout arc: revert skip-to-checkout, slider cart goes active before validation

Mar 23-24 cart/skip-checkout arc (Discord + core-team call). Hardik said the team should 'revert the skip to checkout thing and use the cart thing' while the cart path was still unstable; same-day Discord 'The slider cart is active' appeared before end-to-end confidence. In the Mar 24 call Nick asked 'Why does it open the cart and then leads me to checkout?' A distinct change-management event.

• Reverted skip-to-checkout to slider cart; slider cart activated live before end-to-end validation

Decision to revert cart-skip; cost-per-add-to-cart doubled (cart-skip + Replo both flagged as causes)

Nikita's funnel analysis (same week last month vs this month, and Feb 17-24 windows) showed people moving through the post-product-card funnel dropped by roughly half, with cost-per-add-to-cart up nearly 3x on the capsule text campaign and the gut capsule page CVR falling 4% to 3%. He attributed it to the cart-skip change feeling 'scammy' and to the quantity selector. Hardik named TWO changed variables behind the drop: first, PDPs rendered via the Replow page builder instead of the default Shopify page; second, the direct-to-checkout/skip-cart change. The team agreed to revert to using the cart; Tomide is on the fix and Hardik will re-add the cart immediately after the call.

• revert direct-to-checkout, re-add cart (assigned to Tomide / Hardik)
• PDPs served via Replow page builder instead of default Shopify page (named as a possible cause of funnel drop)

"I buy three bottles... When I click Add to Cart, after that, I expect to get three bottles, and you scam me, of course I'm not going to buy from you."Nikita Lienov

"First reason would be because the Replow page... So that might be one variable and the second variable might be that we are sending directly customer to the checkout page and skipping that cart."Hardik Dewra

Quantity selector showing '1' for multi-pack variants flagged

Hardik flagged that the quantity selector must not show '1' for multi-pack offers, explaining it is a variant ('it is variant, we all know this') but that to the customer it should look like they are getting the three-pack. He said he has made sure of this. Ties to the trust/scam concern about the multi-bottle purchase experience.

• quantity selector display fix for multi-pack variants

"the quantity selector must not show one there, because it is variant, we all know this, but to the customer, it should make... sense that they are getting the three packs."Hardik Dewra

Hardik reports fixing 'gut capsule 3 variant = 1 variant' issue (Francesca took two days)

Hardik reported he was busy fixing a gut capsule issue where '3 variant is equal to one variant' and says he now fixed it. He notes Francesca took two days on a related item. Exact technical nature not fully spelled out beyond the 3-variant-equals-1-variant phrasing.

• gut capsule variant fix (3 variant vs 1 variant)

"I was busy on fixing the gut capsule. 3 variant is equal to... One variant stuff. Now I fixed it. Francesca took two days."Hardik Dewra

Gut Capsule migration verified after Francesca ran bulk ops (all succeeded)

Per the timeline log, on Mar 24 Hardik reviewed a fresh Skio export after Francesca ran bulk ops and confirmed all subscribers were on correct variants; a message to the supplier was drafted. In the parallel Claude session, Hardik reported Francesca had run bulk operations and all succeeded, provided a fresh Gut Ritual subscription export (subscription-export-1774326430821.csv), and asked Claude to confirm whether subscribers previously on the old Kaching bundle subscription had now been migrated to the new structure - focusing only on quantity (the correct quantity shipped for the correct variant = '90% of our job is done'). The export covers only Gut Ritual. He also wanted to message the supplier that future rebuilds will not have the issue, while flagging that already-completed rebuilds might still be on 2-pack/3-pack, and asked Claude to double-check that everyone is on the right variant number. The post-bulk-operation verification step confirming the variant fix succeeded.

• Bulk ops run by Francesca (Skio) - all succeeded
• Post-bulk-op verification of variant assignment (fresh Gut Ritual export)
• quantity-per-variant correctness check
• Drafted supplier confirmation message

"Reviewed fresh export after Francesca ran bulk ops. Confirmed all subscribers on correct variants. Drafted message to supplier."nuora-timeline.html

"Francesca has run some task, which basically means that she has run some bulk operations and all of them succeeded... have they now been migrated to the new one, and if so, is everything fine?"Hardik

Test page with multiple products / SKU IDs and variant IDs attached

Reviewing analytics, Nikita found a page with low CVR (1-2%). Hardik explained it is a testing page where multiple products were tested on the same page, with different SKU IDs and variant IDs attached, designated as the single test page. He noted that for people with access to the Shopify store the page renders differently, so it must be opened incognito. Gut Ritual Stack showed ~10% CVR, ~20% add-to-cart, 600 visitors.

• test page with multiple products, different SKU IDs and variant IDs attached

"This is the testing page. So we were testing multiple products on the same page. And we attached different SKU ID and variant ID to this particular page."Hardik Dewra

Hardik requests read-only Shopify and Skio API access for Claude automation

Hardik asked Nikita for mid-level (not owner-level, not delete-capable) Claude access plus Shopify and Skio access so a Claude automation can fetch real-time data read-only. He stressed he does not want to make changes to Skio or Shopify, only read it, to build a dashboard correlating tests run with conversion/revenue impact. Nikita pointed out a Shopify app with a read-only API key already exists and said he'll set up access later once he understands exactly what Hardik needs. Hardik also reported being blocked from ClickUp Claude connectors and the remote desktop slash command by org policies.

• requested read-only Shopify + Skio API access for Claude automation (pending, Nikita to set up later)

"the Shopify access and the SKIO access it has. I need to take and have a look at the data real-time. I don't want to make any changes. I just want to read the data."Hardik Dewra

Bundle / cart architecture and subscription-discount best practices discussed

Nikita advised the cart bundle must have a good relationship/architecture with the cart so subscriptions, discounts, bundle selection, correct pricing, no lag, and multi-currency all work - usually solvable through Liquid following best practices. Hardik confirmed he already has a custom cart functionality built (interactive/functional) and will implement the cleaner cart layout after the call. No specific Skio selling plan IDs, billing intervals, or Kaching exploits discussed.

• cart/bundle architecture guidance (subscriptions, discounts, pricing, currencies via Liquid)

"making sure that the bundle has good relationships with your card... then everything is going to work in terms of subscriptions, in terms of discounts, in terms of selecting the right bundle, making sure the price is correct."Nikita Lienov

Nuora Offer Engine migrated to JSON files (GitHub), built with Claude

Hardik reports he built a 'Nora offer engine' on GitHub and, per Nikita's prior instruction, migrated it to use JSON files across the board (rather than markdown) so offer/test data is structured. Nikita reinforced a structured database (Postgres/JSON, columns+rows: hypothesis, variant A/B screenshots+explanations, traffic, add-to-cart %, CVR, revenue) is the source of truth for split-test tracking. The offer engine governs how offers/SKUs/pricing variations are represented and is the data backbone Hardik wants the read-only Shopify/Skio feed to populate.

• Nora offer engine rebuilt on GitHub using JSON files across the board (built with Claude)
• split-test tracking database design discussed (columns/rows, variant A/B, traffic, ATC%, CVR, revenue)

"Nora offer engine, okay, wait, let me show you the Nora offer engine, which I made on GitHub, and you told me that I need to use JSON files, and now it is all using JSON file across the board."Hardik Dewra

Claude/AI used to build PDP/cart assets via Paper MCP and to handle counterfeit complaints

Multiple Claude/AI usages: (1) Hardik built a UI/asset (cart/page) 'everything Claude did on the paper MCP' in a few hours, still fixing bugs. (2) Hardik plans to have Claude code auto-file trademark/counterfeit complaints against scam stores ripping the Nora store - he notes only the store owner can file (so it is gated). (3) Nikita described using Claude with a structured prompt + extracted Magic Patterns page + a recorded advertorial MP4 to make advertorial/page generation 'more smart'. Shows the team's AI-assisted operations workflow feeding storefront/SKU work.

• UI/asset built with Claude on Paper MCP (a few hours, bugs pending)
• Claude code to auto-file counterfeit/trademark complaints (store-owner gated)
• Claude-driven advertorial/page generation pipeline (prompt + Magic Patterns extract + recorded MP4)

"This is all made by AI, everything Claude did on the paper MCP... it took me like some hours to build it."Hardik Dewra

Lucky (supplier) issue reported fixed across the board; bonus/distribution under review

In the Hardik-only segment after Ollie leaves, Hardik reports the problem with 'Lucky the Supplier' is now fixed across the board and posted to the Slack channel. Fallout: a bonus/distribution question - Nikita says it is a shared Hardik+supplier issue because Hardik 'did not control that she actually locked it in', but he will not deduct, only redistribute the bonus per a scheme Ollie proposed, deciding strictly on data. Relevant to the operations/fulfillment handover (Lucky is fulfillment ops).

• supplier (Lucky) issue resolved across the board, posted in Slack
• bonus-distribution review (no deduction; redistribution per Ollie's proposed scheme)

"The problem which we were having with Lucky the Supplier, it is now fixed across the board, and you know, on the Slack channel."Hardik Dewra

Counterfeit/parasite stores and Amazon capsule rip-offs of Nuora

Ollie and Hardik report dozens of scam/parasite stores ripping the Nora store ('dozens and dozens and dozens'), plus capsule rip-offs of the Nuora gut capsules now on Amazon. Nikita says everyone faces this and the only answer is to move faster. Not a Skio/subscription operation, but a brand-protection incident affecting the gut capsules SKU.

• brand-protection: many counterfeit/parasite storefronts + Amazon capsule rip-offs identified

"We even have capsules, rip-offs now on Amazon."Ollie Trott

Core-team call: Nick restates cart-always-beats-no-cart; defines variant A/B test record structure

On the Mar 24 core-team call (a cart/skip-checkout-arc and CVR-debugging call, NOT a Skio/bulk-change call), Nick restated 'We always use cart, every single time is split tested against no cart and cart, and no cart always, always, always fails' and Ollie noted 'sometimes it would add to cart and then skip it'. Nick also specified the experiment-record structure for variant testing: hypothesis, screenshot of variant A, screenshot of variant B, amount of traffic launched, CVR. Elliot is NOT mentioned on this call (he appears only on the Mar 31 performance call).

• Defined A/B variant test record fields: hypothesis, variant A screenshot, variant B screenshot, traffic, CVR
• Discussion of cart vs no-cart split test

"We always use cart, every single time is split tested against no cart and cart, and no cart always, always, always fails."Nick

"hypothesis, screenshot of variant A, screenshot of variant B, amount of traffic launched, CVR"Nick

Hardik implements custom cart as source of truth without testing; rolled back

In the Mar 26-30 Discord arc, Hardik wrote the custom cart was 'all on assumptions that the new cart with upsells and crossells is better than the previous one' and admitted 'i implemented it as the source of truth without doing the testing.' Four days later (Mar 30): 'just turned this off, the new cart is not converting good.' Ollie pushed back 'is this based in data?' and 'we cant keep making assumptions g.' A concrete implement-then-rollback incident (CRO funnel cart, not Skio subscription billing).

• Custom cart (upsells/crossells) implemented as source of truth without testing, then rolled back after underperforming

MRR gap identified - zero MRR flagged by Ollie

Per the timeline log, on Mar 29 Ollie flagged zero MRR. Hardik confirmed there was no MRR, only $2.9K showing, and DM'd Ollie with details. An early signal of the MRR-forecast/reporting issue later raised with Elliot.

• MRR reporting anomaly investigation

"Ollie flagged zero MRR. Confirmed: no MRR, only $2.9K showing. DM'd Ollie with details."nuora-timeline.html

Gut Ritual analysis Claude session resumed (/resume)

The Gut Ritual analysis session was resumed via the /resume command. No additional substantive content followed in this archive.

• /resume

Shipping Logic Gate repo: Golden Rule (ship variant-name bottle count, never variant x quantity); legacy migration still in progress

README for the 'Nuora Gut Capsule - Shipping Logic Gate' repo, a visual fulfillment decision guide built because Nuora migrated Gut Ritual (Gut Capsule) from Kaching Bundles to Skio Selling Plans. Two coexisting order types post-migration: Skio (quantity always 1, variant name = bundle size) and legacy Kaching (inflated quantity). Golden Rule: the number of bottles to ship is always the number in the variant name, never variant x quantity. Examples: '3 Bottles x Qty 3' ships 3 bottles (not 9); '2 Bottles x Qty 2' ships 2 bottles (not 4); '1 Bottle x Qty 1' ships 1 bottle. Product ID 8400072802444; variant IDs 45566109089932 (3 Bottles) / 45566109057164 (2 Bottles) / 45566109024396 (1 Bottle). Hosted at hardikdewra.github.io/nuora-gut-capsule-logic-gate (+ Vercel). STATUS: at the documented point in time legacy Kaching subscriptions were STILL being migrated to the new Qty 1 Skio format - both order types were flowing to the supplier simultaneously (the reason the logic gate was needed). Remaining legacy subscription count NOT stated. Date = repo last-commit hint; exact build date not stated.

• fulfillment logic gate / shipping decision guide
• legacy subscription migration to Qty 1 Skio format (in progress, incomplete)

"The number of bottles to ship is always the number in the variant name. Never multiply variant x quantity."README

"Legacy subscriptions are being migrated to the new Qty 1 format via Skio. Once complete, all orders will be clean and only the variant name will matter."README

Core team realizes subscription MRR not materializing despite 79,000 subscribers; ~$100k/day target missed

On the weekly core team strategy call, Ollie and Nikita pressed on why MRR was far below the ~100k/day target despite a large subscriber base. Nikita stated they have 79,000 people in the subscription program and asked where the revenue was going. His hypothesis: the billing-frequency variables (every 1 month / 2 months / 3 months) were the cause - people previously paying monthly now had longer durations and lower billing frequency, so revenue came in slower. Hardik tied the MRR shortfall to the bulk migration ('We'll have it tomorrow because of the bulk migration thing') and noted Kira ('Kirai' in transcript) had raised the same MRR question on the Slack channel. Ollie explained an early-month MRR spike pulled revenue forward, leaving the last week light; a projected later spike came in ~half its expected size, compounded by the cart changes breaking the cart for much of the month so he couldn't scale ads (margins compressed all month). Treated as urgent (a matter of hours) to protect chargeback rate.

"Wait, it still doesn't answer the question, where is the revenue, if we have so many subscribers, where is the revenue from the subscribers?"Nikita

"I have an assumption that the thing with variables, you know, like every one month, every two months, every three months, I think this is what us."Nikita

"because we had those cart changes, it us for the whole month, because then I couldn't scale as quickly as well... our margins just being compressed the whole time."Ollie

Nikita directs Hardik to urgently get Elliot to diagnose billing-frequency revenue problem; floats one-month transfer

Nikita instructed Hardik to figure out with Elliot, today and urgently, why increased subscribers were not producing increased revenue, framing it as a matter of hours because chargeback rate was rising as front-end volume dropped. He floated, as a last-ditch option, transferring everybody to a one-month billing frequency (hypothesis: lengthening duration and reducing billing frequency on subscribers who previously paid monthly was suppressing revenue). Hardik agreed it might be the only option. Earlier Hardik separately said he needed to talk with Elliot about reordering the cancellation-reason options in the churn flow (top reason 'I subscribed by accident', possibly because it was the first option listed), though Nikita at one point told him not to speak to Elliot about that.

• Possible last-ditch bulk transfer of all subscribers to one-month billing frequency (proposed, not executed)
• Planned: ask Elliot to reorder the cancellation-reason options sequence in the cancel flow

"Hardik, figure out with the Elliot, today, urgently, say, we are getting cooked, our chargeback rate rises because the volume drops, we keep having more subscribers, we have 79,000 people in the subscription program. Why are we not getting increased revenue?"Nikita

"as the last ditch decision, we might... Transfer everybody in one month."Nikita

New cart with upsell/cross-sell DECREASED CVR and nearly doubled cost-per-purchase; cart broken much of the month

Hardik reported a 'crazy learning which cost us a lot': he assumed the new cart (with upsell/cross-sell, e.g. prompting gummies buyers to add Gut Capsules) would convert higher, but CVR decreased. Ollie confirmed: 'CVR decreased and the cost per purchase has almost doubled today, across the board.' Ollie tied a full month of compressed margins to these cart changes leaving the cart broken so he couldn't scale ads. The operational root cause repeatedly referenced as 'the cart changes' that interacted with the MRR/chargeback problem.

"Bro, CVR decreased and the cost per purchase has almost doubled today, across the board."Ollie

Cart UX/copy friction list Nikita gave Hardik ('every three months' label, repeated total price, 'secure checkout')

Nikita walked Hardik through cart friction to fix: (1) discount needs a justification ('cheaper together'); (2) added-to-cart doesn't show strike-through/discount reasoning; (3) the cart shows 'every three months', creating subscription friction and differing from the previous variant; (4) total price repeated too many times; (5) remove 'every one month' from the card description; (6) Nikita split-tested 'secure checkout' vs 'checkout' and 'secure checkout' won. Concrete CRO/cart directives tied to the subscription variant labels.

"It says every three months in the cart, which probably also creates friction... because people think, every three months, they keep thinking about subscription."Nikita

"I split test checkout versus secure checkout, and it had really good updates."Nikita

Churn-flow: 'I subscribed by accident' likely an artifact of being the first option; Hardik to ask Elliot to reorder

Hardik explained the #1 cancellation reason when churning was 'I subscribed by accident' (customers said they didn't know they would be recharged/rebilled). He suspects this is skewed because it was the first option listed, so he wants Elliot to reorder the cancellation-reason options to validate the real reason. Nikita interjected 'don't speak to Elliot' (re: the retention/email agency deal context). Directly relevant to subscription retention/churn operations.

• Planned: ask Elliot to reorder the cancellation-reason options sequence in the subscriber cancel flow

"the number one reason was I subscribed by accident. So I just wanted to eliminate that reason... it makes sense that they might be choosing it because it was just the first option."Hardik

Chargeback rate double the 0.3 threshold; payment processing at risk; 90% of refunds are Gut Capsules

The team confirmed the chargeback rate is roughly double the threshold. Ollie corrected the threshold from 0.5 to 0.3 and noted Visa is about to lower it further; if chargeback rate stays too high they get payment processing banned. Nikita set priority order: protect profits/margins first, then address chargeback rate; they can't scale down because front-end volume is needed. Nikita's analysis: 90% of refunds are 'gap capsules' (Gut Capsules), attributing the cause to a supply-chain issue plus post-purchase emails (Ollie clarified these were the post-purchase emails a customer receives, not the ones he communicated on Slack); actively being resolved.

"My understanding was if our chargeback rate is too high, we literally just get our payment processing band, and then we're [done]."Ollie

"90% of our refunds are gap capsules. Why? Something is wrong with supply chain and post-purchase emails."Nikita

Nikita prioritizes hiring a dedicated operations manager (origin of the Nadia role mandate)

Wrapping the call, Nikita said his number-one goal was hiring a dialed-in operations manager to take supply chain, chargeback rate, payments, calculations, and bonus payouts off the team's plate and automate them. He said the current operations manager is 'nowhere near our level'. This call is effectively the origin of the operations-manager role mandate, scoped around the same chargeback/subscription pain - directly relevant context for the handover to Nadia.

"the one that's really dialed in operations manager, I really want her, or him, whoever it is. So that's my number one goal right now."Nikita

Skio MRR issue - Hardik drafts message to Elliot re: forecast mismatch and rising chargebacks

Per the timeline log (post a Nikita call) and a parallel Claude session ('MRR Problem Nuora - Elliot Thread'), Hardik drafted a message to Elliot Mitchell (Skio) about the MRR forecast not matching historical data, noting chargeback rate was climbing while volume was dropping. He opened the draft with 'Hey Elliot, thank you for replying to Kira on Slack, not me on Slack' at first, then rejected the first draft for sounding like AI ('Bro, why are you writing like AI?') and asked Claude to write simply in his own voice. He asked Claude what 'chargeback rate increasing/climbing while volume is dropping' meant (the only chargeback mention in that archive; no chargeback numbers preserved). Nikita had specifically asked him to text Elliot following the call. Core complaint: the forecast's previous historical data did not match historical trends, so the upcoming prediction ('queue model') could not be trusted. The 702-line Fathom transcript + 4 images that gave the substance are NOT preserved in the archive.

• Drafted Skio MRR-forecast/chargeback message to Elliot (via Claude)

"Drafted message to Elliot about MRR forecast not matching historical data. Chargeback rate climbing while volume drops."nuora-timeline.html

"write me a message to Elliot and start with "Hey Elliot, thank you for replying to Kira on Slack, not me on Slack", and then ask him how to fix the MRR problem"Hardik

"Bro, why are you writing like AI? ... write simply so it is easier for him to understand, as well as it seems that I have not written shit with AI."Hardik

Performance call: Nick says let Elliot gather his own data; effort != impact

On the Mar 31 performance call, Nick told Hardik that effort does not equal impact, that Hardik had created tasks for others, and that he closes loops by creating interpretation work. Nick's concrete alternative included 'Let Elliot spend his own time... gathering the data that I want,' framing Hardik's choice to do a call rather than gather context himself. Elliot is referenced on this call (and the Mar 24 call did NOT reference Elliot per the source).

• Coaching on ownership/loop closure re Elliot data gathering

"Let Elliot spend his own time... gathering the data that I want."Nick

"Effort doesn't equal impact. Never"Nick

Chargeback root-cause analysis doc authored (3 ranked causes + 1 bonus)

A root-cause analysis of Nuora's high chargeback rate, written first-person (not explicitly named as Hardik in the doc; external hint 2026-04, no date stated). Opens 'Three potential reasons, ranked from highest to lowest conviction', with the bonus labeled 'Reason 3.14159...' (a pi joke signaling a non-primary, compounding factor). Cause 1 (high conviction): wrong quantities shipped post-migration (3PL shipped qty 1 instead of subscribed 3 and 2). Cause 2 (medium): removal of exploited Ka-ching Bundle $0.00 discounts caused those cards to suddenly bill the real amount. Cause 3 (low/speculation): premature 'order reserved' emails to Gut Capsule customers during low CNY inventory. Bonus: blizzard + Chinese New Year shipping delays compounding the others.

Two Loom videos posted on Lucky Ops channel ahead of bulk migration

As part of the bulk migration process, Hardik sent 2 Loom videos on the Lucky Ops channel, 2 days in advance before the bulk migration on any of the products, to guide fulfillment on correct quantities. Rei watched them the very next day, but Lucky did not view them until the doc-writing day, when Hardik prompted her.

"Rei watched them the very next day, but Lucky did not view them until today when I prompted her to."Hardik

FALLOUT: 3PL shipped quantity 1 instead of subscribed 3 and 2 (chargebacks) - highest conviction

After the bulk migration, customers who were supposed to receive quantities of 3 and 2 all received quantity 1 instead. This directly caused customers to file chargebacks because they were billed for a quantity they didn't receive. Identified as the highest-conviction cause of the elevated chargeback rate. This is the downstream consequence of the Jan-30/Feb migration step where the variant swap was run WITHOUT adjusting quantity and post-swap fulfillment quantity was never verified.

FALLOUT: Ka-ching Bundles exploit discount removed; $0.00 customers chargeback - medium conviction

Nuora removed the hard-coded Ka-ching Bundles discount customers were exploiting to get products effectively free. These customers had their cards billed at $0.00 for many months; once the exploit was removed their cards suddenly started getting charged the actual amount, and they filed chargebacks in response. The discounts were removed before the bulk migration date, so these accounts are no longer visible in current data; the only retained evidence is Hardik's screenshots of prior examples (the sole artifact that can substantiate this cause). Medium conviction; more data needed but may not be retrievable.

"We removed their discounts before the bulk migration date, so we won't be able to see these accounts in the current data anymore. I have screenshots of prior examples for reference."Hardik

FALLOUT (speculative): premature 'order reserved' emails to Gut Capsule customers - low conviction

Ollie mentioned he accidentally sent emails to some Gut Capsule customers telling them their order was reserved and to rest assured. But Gut Capsule inventory was low due to Chinese New Year, so those customers may have filed chargebacks after not receiving products for an extended period. Lowest-conviction cause; Rei needs to confirm and there is no specific data.

FALLOUT: blizzard + Chinese New Year shipping delays compounding chargebacks

A significant number of shipments were delayed or lost in transit due to a recent blizzard and Chinese New Year disruptions. Customers who hadn't received orders within expected timeframes filed chargebacks. Treated as a contributing factor compounding all three primary reasons (the 'Reason 3.14159' bonus) rather than a standalone cause.

Chargeback doc structure: order-of-conviction ranking (3 ranked + 1 bonus)

The chargeback root-cause doc explicitly opens (line 5) with 'Three potential reasons, ranked from highest to lowest conviction.' The bonus is labeled with a pi joke 'Reason 3.14159...' to signal a non-primary, compounding factor. This deliberate ranking/structure is the analytical spine of the chargeback handover (date not stated in source; external hint 2026-04).

Chargeback doc: screenshots of prior Ka-ching exploit examples retained as the only evidence for Reason 2

Because the discounts were removed before the bulk migration date, the exploiting accounts are no longer visible in current data, and the only retained evidence is Hardik's screenshots of prior examples ('I have screenshots of prior examples for reference'). For Nadia's handover this is the sole artifact that can substantiate Reason 2 (Ka-ching $0.00 exploit removal -> chargebacks); its existence/location is an actionable follow-up (date not stated in source).

Discord wins-post session (Apr 1-2) embeds the Mar 31 strategy-call transcript; Fathom link recorded

A Claude Code session (Apr 1-2 2026) where Hardik drafts Discord wins posts about A/B tests (mostly not Skio-related). The Skio-relevant material is an embedded voice transcript of the March 31 Core Team Strategy Call. The transcript header includes the Fathom recording link for the Mar 31 call (Core Team | Strategy Call - March 31, 60 mins): https://fathom.video/share/fwmZeXpQa2wpzq7zgVMa5v6iEhMtzR-f - attached as source_link on the Mar 31 events.

April 7 strategy call: MRR/daily-revenue decline traced to Kari's billing/order-delay running since Feb 27; Elliot call deferred

On the April 7 strategy call, Hardik told Nikita he had a call with Elliot in ~2 hours 'regarding the MRR thing.' The last thing Hardik tracked was a billing 'delay' mechanism (transcribed 'Kari's delay regarding the billing') running since '27th of fab' (27 Feb 2026), which he only figured out the day before/two days before. He had asked Elliot for data on how many customers per day clicked the link to delay their orders. Nikita said he 'found the solution today', told Hardik not to worry ('I'm fully on it. the daily revenue is decreasing') and to focus on front-end acquisition (CVR, add-to-cart, checkout). Nikita said 'There is another person that is taking care of subscriptions right now' so he didn't need to join the Elliot call.

"You have a call with Elliot in about two hours, right? Regarding the MRR thing... the last thing I was able to track was Kari's delay regarding the billing and it was running since 27th of fab."Hardik Dewra

"There is another person that is taking care of subscriptions right now. Okay. So I don't need to join the call with Elliot."Nikita Lienov

Subscription billing delay raising 'delay rate' while churn dropped

Hardik raised a tension: churn was getting lower but the 'delay' (the billing-delay mechanism running since 27 Feb where customers click a link to delay orders) was getting higher, and asked how they'd scale. Nikita's direction: Hardik should step off subscriptions entirely and focus on front-end acquisition (CVR, add-to-cart, checkout conversion rate vs the past 30 days), leaving subscriptions to the other person handling them.

"on one hand, churn is getting lower, but the delay is getting higher. So we have to choose a path"Hardik Dewra

April 7: Kaching bundle quantity-adjust exploit recalled; quantity adjuster + 'three bottles'/guarantee removed from cart

Comparing UpCart vs custom cart, Nikita observed there was no way to adjust quantity and that one cart said 'three bottles' while the other said nothing. Hardik explained the quantity adjuster 'can only be added if we have the coaching [Kaching] bundles thing', and it used to exist 'prior when we had coaching [Kaching] bundles, but then the people would exploit it by reducing the quantity and then it would cause issues', so it was removed. The 'three bottles' line and a guarantee element could only exist with the Kaching Bundles discount coupon; without it they cannot be shown. Documents the original Kaching quantity-reduction exploit that motivated moving off Kaching. Retrospective discussion (removal date unstated, 'used to be there prior'); a Nuora cart/checkout UI fact, not attributed to specific SKUs.

• Kaching Bundles removed from cart; quantity adjustment removed; guarantee element removed (depended on discount coupon) - retrospective

"it used to be there prior when we had coaching bundles, but then the people would exploit it by reducing the quantity and then it would cause issues"Hardik Dewra

Plan to double MRR via subscription cadence change (30-day billing optimized for 90-day LTV)

Nikita said that after implementing his planned changes they would 'essentially double the MRR' and 'own our customer base'; Ollie confirmed it was 'literally just changing the cadences.' Nikita pointed to a written note: a '100% subscription take rate offer on a 30-day billing cadence optimized for 90-day LTV', programming customers to treat a 90-day commitment as the baseline. He acknowledged a 30-day cadence is 'more sustainable than we have right now, but not as sustainable as having one' longer plan. Planning/idea stage, not executed.

• proposed subscription billing cadence change to double MRR (30-day billing, 90-day LTV)

"after implementing ... the changes that I have an idea for, we will essentially double the MRR"Nikita Lienov

"it's literally just changing the cadences, right?"Ollie Trott

Core-team call: Nick asks again (3rd time) for centralized variant/experiment-test system

On the Apr 7 core-team call, Nick asked why Hardik still did not have the centralized experiment/CRO record system, noting it was the third time he had asked. Discussion also covered being 'not able to yet figure out what is the variable', with Ollie stressing 'the tiniest variable makes such a huge impact... just always asking why, why, why?' Relevant to the experiment/variant record system tied to the variant testing and CRO work.

• Repeated request for centralized experiment/CRO record system

"Why do you still don't have the... centralized system"Nick

"No, it's third time I'm asking you to do this."Nick

Gift offer thread: Nick says repeating same mistake, test on small cohort, no supplier needed

Apr 11-12 gift offer thread. Ollie first pushed Hardik back to customer logic/friction; Nick said 'you're repeating the same mistake over and over again', 'test on a small cohort, in a controlled environment', and 'you don't need a supplier for this.' Hardik asked Lucky too early then said 'i have deleted the message' once Nick reframed. The most-recent recurrence cited, involving the supplier/test-design pattern relevant to operations decisions.

• Gift offer: Nick mandated small-cohort controlled test, no supplier contact; Hardik retracted a premature message to Lucky

L60D Performance Case File compiled for Nick; references 2 Skio/bulk-change Fathom calls and the same product/variant ID risk

Hardik's L60D Performance Case File (period 2026-02-11 to 2026-04-12, prepared for Nick) was compiled. Methodology: 13 Fathom transcripts reviewed (weekly core-team calls 2026-02-03 through 2026-04-07, '2 relevant Skio/bulk-change calls', and 2 March 31 impromptu calls); 6,776 Discord messages across 346 threads, 2,239 Hardik-authored. Documents the Skio bulk-change decision history primarily through the 2026-02-27 call. Counterevidence note: 'He can identify structural issues when the problem is concrete, such as the same product/variant ID risk' (no date/product/context given for when this was raised - do not assert it occurred during the Skio/bulk-change work). No Fathom URLs, SKU IDs, variant IDs, or subscription counts in this source.

"Fathom calls reviewed: 13 total ... 2 relevant Skio/bulk-change calls, and 2 March 31 impromptu calls"Hardik (case file)

"He can identify structural issues when the problem is concrete, such as the same product/variant ID risk."case file

Case file flags 'same product/variant ID risk' as Hardik's structural insight

The compiled case file (2026-04-12) notes as counterevidence that Hardik can identify structural issues when the problem is concrete, citing 'the same product/variant ID risk' - the variant/SKU structural risk surfaced during the Skio work. The source gives NO date, product, or detail of when he raised it.

• Hardik flagged same product/variant ID risk (structural insight re variant restructure)

"He can identify structural issues when the problem is concrete, such as the same product/variant ID risk."case file

Hardik flags Skio subscription cadence review (3-month/2-month to 1-month); Nikita defers as backend

During the core team strategy call, Hardik told Nikita he was reviewing a request from the Skio team posted in the Skio Slack channel about subscription cadence, asking whether Nuora was moving from three-month and two-month intervals to a one-month interval. Nikita said Hardik did not have to worry about it, calling it a backend thing, and said it was all good. No decision was made and no operation described - raised and deferred. The only subscription/Skio reference in an otherwise CRO/advertorial-focused call. Source does not name which product the cadence question applies to.

• Reviewing Skio Slack channel request on subscription cadence (3-month / 2-month possibly moving to 1-month) - no operation run, deferred as backend item

"So on Skio, on the Slack channel, they asked you to review and use your Slack. I'm reviewing it, the cadence thing. So are we going from three months and two months to one month thing now or not?"Hardik

"You don't have to worry about this right now. It's a backend thing... I explicitly told you, you don't have to worry about this. It's all good."Nikita

Tomide fired and replaced by new developer Aman (first reference)

A later user message in the wins-post session file states: 'update is we fired tomide and now hired a new developer to join the team, his name is aman.' Confirms the Tomide->Aman developer transition. Not a Skio operation, but a team-roster change relevant to who will execute future subscription/SKU/Kaching fixes. (The May 5 call later details the removal date and Aman's background.)

"update is we fired tomide and now hired a new developer to join the team, his name is aman"Hardik

Hardik reverted the variant-bundle migration back to Kaching Bundles after ROAS crashed to ~0.8-0.85

On the April 21 one-on-one with Nikita, Hardik reported front-end ROAS had crashed to ~0.8-0.85 (shown by Oli the prior day). He isolated the variable he believed responsible: the move from Kaching Bundles to the new variant structure where 'one variant is equal to three packs and one variant is equal to three bottles', and he reverted BACK to using Kaching Bundles. He updated the supplier and made an arrangement with Tomide to use a percentage discount so people cannot exploit the store, and configured it so that when someone decreases the quantity it not only decreases the quantity on that variant but also switches the variant accordingly. Despite reverting, metrics still hadn't improved, so he asked Nikita to dig into the data. (The source does not name which products the new variant structure applied to.)

• Reverted migration from new 1/variant-per-quantity structure back to Kaching Bundles
• Switched Kaching Bundles discount to percentage discount (anti-exploit) via Tomide
• Configured cart so reducing quantity also switches the variant accordingly

"we moved from Kaching bundles to this new variant, where one variant is equal to three packs and one variant is equal to three bottles. Now we are back to using Kaching bundles."Hardik

"I have made an understanding with Tomide that please use the percentage discount so that people aren't able to exploit us."Hardik

LTV understated because variant migrations not yet reverted to one-to-one

Discussing North Star metrics (3-month LTV from Skio/Triple Whale, CAC-to-LTV target 3:1), Hardik warned the LTV shown now would be much worse than it would show a couple of months later, because 'we just did the migrations and we haven't reverted the migrations back to one is to one.' Nikita agreed. Ties the recent subscription variant migration directly to depressed LTV/ROAS and indicates the planned revert to a one-to-one variant structure had NOT yet completed as of April 21.

• Planned but not-yet-completed revert of variant migrations back to one-to-one

"the LTV it will show right now would be like much worse than it would be showing. A couple of months from now, because we just did the migrations and we haven't reverted the migrations back to one is to one."Hardik

Subscription take rate pulled via Triple Whale Moby: Gummy ~72%, Capsule ~78%

Nikita asked Moby (Triple Whale AI) to calculate the blended subscription take rate per product for first-time customers over the last 7 days, using the 'subscription first order' customer tag. Result: 72% (Gummy) and 78% (Capsule). Nikita framed subscription take rate + subscription AOV as the two metrics driving CAC-to-LTV, noting a brand can be unprofitable at 70% take rate but very profitable at 85% and 100%. Nikita stated Nuora has two products total - 'One is Gummy, second is Capsule... They might have different kind of SKUs.'

• Moby (Triple Whale AI) queried subscription take rate per product for first-time customers, last 7 days

"We have 72% subscription take rate, 78% subscription take rate. You can see here, Gummy Capsule."Nikita

"In total, we have two products. One is Gummy, second is Capsule. They might have different kind of SKUs, whatever"Nikita

Hardik reverted site-wide CRO test changes (UpCart restored, direct-to-checkout removed) - ROAS still down

Beyond the variant/Kaching revert, Hardik reported he went back through the CRO/A-B tests run on the whole Nuora site over the prior month(s), isolated the variables, and reverted them - explicitly bringing back UpCart and getting rid of the direct-to-checkout flow. Despite these reverts the front-end metrics/ROAS still did not recover. Shows the variant revert was one of several simultaneous reverts, confounding diagnosis.

• Reverted site-wide CRO A/B test changes across all Nuora pages
• Restored UpCart
• Removed direct-to-checkout flow

"the test I ran on whole sites, like full, full Minora pages... I took those variables and then I reverted them as well. Which was to bring back UpCart, bring back, to get rid of the direct to checkout and still the metrics aren't looking good"Hardik

Elevate A/B test data untrustworthy - 'one-timer' purchases on a 100%-subscription Gut Capsule offer (ran twice)

Hardik reported the Elevate A/B testing tool is showing wrong data and cannot be trusted. On a Gut Capsule test he built a new offer eliminating the one-time-purchase option (intended 100% subscription), yet Elevate reported one-time-purchase ('one timer') orders on it; he re-ran the test and it again showed one-timer purchases despite no one-time option existing. He reached out to the Elevate team (who said they're looking into it; Nikita also reached out). Plan: stop trusting Elevate, move testing to Facebook ABO with Oli sending traffic directly. Undermines confidence in prior subscription-vs-one-time data.

• Ran Elevate A/B test on Gut Capsule with one-time option removed (100% subscription intended); Elevate falsely reported one-timer purchases; test re-run, same result; Elevate team notified

"I tested that new offer out against control and it was showing me one timer have been purchased from the new offer, which was really weird because there was no option to buy from one timer for people"Hardik

Hardik told Tomide to duplicate feminine balance gummies page x2 and add SessionVision; re-validate flagged tests via Facebook ABO

After distrusting Elevate, Hardik told Tomide to duplicate the feminine balance gummies product page twice to re-test (via Facebook ABO traffic from Oli) whether previously Elevate-tested elements actually convert: the '100% real' element, the counterfeit warning label (tested on the gut capsule), and the '88% remaining' new checkbox. He is incorporating SessionVision session-tracking and told Tomide to add it. (Also part of the broader site-wide revert: re-enable UpCart, remove direct-to-checkout.)

• Told Tomide to duplicate the feminine balance gummies product page twice for ABO re-testing
• Re-testing elements: '100% real', counterfeit warning label (gut capsule), '88% remaining' checkbox
• Told Tomide to add SessionVision tracking

"have told Tomide, Tomide, duplicate the feminine balance gummies one page twice... the 100% real thing we tested and the counterfeit warning label I tested also on the gut capsule the 88% remaining the new checkbox thing we tested"Hardik

Hardik pastes L60D case file into Claude asking how to show improvement before a meeting

Hardik opened a Claude Code session (2026-04-21) and pasted his entire L60D Performance Case File, asking what to do in 2 hours to showcase he had improved. Claude advised against faking change, recommended a decision framework, a centralized experiment tracker, and one high-leverage proposal, and offered to dig through his Nuora folder. No Skio bulk operations, GraphQL mutations, variant IDs, or AI subagents running subscription operations - a coaching/communication-prep conversation referencing the prior Skio bulk-change history secondhand via the case file.

"Real talk: 2 hours can't fake 60 days of change. But you can flip the story from 'same patterns' to 'already building the fix' with the right artifacts."Claude

Downloads folder reorg surfaced Nuora Skio/SKU work artifacts (no operations run)

In a Claude Code session beginning 2026-04-22 (spanning to Apr 29), Hardik asked Claude to reorganize ~/Downloads into structured subfolders. During inventory/move steps, Claude catalogued and moved many Nuora Skio/subscription/SKU artifacts (mv only, with a backup + move-log at ~/downloads-reorg-backup-2026-04-22). NO subscription/variant/billing/Skio/Shopify operation was executed - pure filesystem organization. Files moved into ~/Downloads/Nuora/Data-Exports/ and Screen-Captures/ include: skio-meeting-prep.md, skio-meeting-notes-for-elliot.md, nuora-chargeback-analysis.md, 'Bulk Migration_Operations Planner.md', 'Nuora Optimisations - Bulk Operations Stuff.csv', nine 'self-serve-bulk-operations-preview-export-*.csv' (Skio preview exports), 'audit-logs-export-1775125482205.csv', fifteen 'subscription-export-<epoch>.csv' (epochs 1771252896476-1775051563588, up to 122M), 'Nuora_Subscription_Revenue_Analysis.xlsx', 'nuora-mrr-analysis-apr2026.csv', 'NUORA MASTER PRODUCTS SHEET - Sheet1.csv', 'Subscriptions sales over time - 2025-08-01 - 2026-02-25.csv', 'change sku to 2 bottles.xls', 'change sku to 3 bottles.xls', 'screencapture-skio-2025-11-09-01_55_44.png', and 'Nuora . OrderEditing.com . Shopify Plus.png'. ('6 SKU orders.xls' surfaced only as a NEW post-reorg top-level file, never moved.) These FILENAMES (contents never opened here) likely hold the real operational detail for Nadia and should be read directly. Folder-hygiene flag: the reorg glob also incorrectly moved BLOOMIN (excluded brand) CSVs into Nuora/Data-Exports/ - recommend re-filing them out of the Nuora folder.

• Downloads folder reorganization via mv (backup + move-log). No Skio/Shopify operations executed.
• FLAG: Bloomin CSVs incorrectly globbed into Nuora/Data-Exports/ - re-file out of the Nuora folder

May 3 Claude session: transcript review to identify the testing lab (SGS), not hands-on Skio work

On 2026-05-03 Hardik pasted four concatenated core-team strategy-call transcripts (April 7, 14, 21, 28) into Claude and asked it to find the name of the testing/certification company Nikita mentioned. Claude answered SGS, citing the April 14 call (~1:23:46) where Nikita pitched 'certificate of ingredients provided by SGS' / 'tested on honesty of ingredients by SGS' (a 'world renowned lab'). No Skio admin, GraphQL mutations, or bulk operations performed - transcript review only.

"Found it. The company is SGS."Claude

Core Team Strategy Call (99 min): cadence change held/monitored; revenue/cancellation impact discussed

On the May 5 strategy call, Nikita raised the cadence changes himself (Ollie only interjected 'What?'), saying he had waited and not pulled the trigger yet, monitoring because subscribers keep accumulating. He framed the cadence change as needing a sustainable offer locked in first, then doing the switch. He warned that as cadences change, cancellation rate will rise (more subscriptions posted daily) and revenue would move from current levels to ~200-300k/day, requiring matched ad-spend increases. Called it urgent ('every single day super urgent'), might pull the trigger before the end of that week. The still-pending billing-interval/cadence switch tied to the subscription SKU restructure.

• Subscription cadence (billing interval) change - planned/pending, not executed

"What is happening with the cadence changes? It is something that I, for now, waited upon. So I have this thing, I didn't pull the trigger yet."Nikita Lienov

"as we change the cadences, our cancellations rate will increase because we will have more subscriptions being posted every single day. Our revenue will go from current revenue to around 200-300k per day."Nikita Lienov

Chargeback rate stated as decreasing post-migration; support locked in

Ollie raised that chargeback rates would increase with the cadence change. Nikita pushed back: it would not, because support is now locked in well, the chargeback rate is decreasing, and everything is better on the back end. The cadence switch is driven by needing a sustainable long-term offer, not by chargebacks. Indicates the post-migration chargeback/3PL fallout had been brought under control by early May.

"Yeah, I know, because chargeback rates will increase."Ollie

"Not because, no, it will not. We have locked in the support right now very well. Our chargeback rate is decreasing, support is much better, everything is better on the back end."Nikita Lienov

Gummies Tea pre-lander ran with broken/missing pricing on Kaching, skewing performance data

Reviewing 30-day landing-page performance, Ollie flagged the Gummies Tea pre-lander results were skewed because it had run without proper pricing - the pricing was not showing on Kaching (Kaching Bundles). He had gone back through it, found the missing pricing, and sent Tom (Tomide) a screenshot in Discord. Nikita confirmed the data 'was not correct in the first place.' A Kaching Bundles pricing/discount misconfiguration affecting a live subscription product page; source does not say it was fixed (Tomide was being removed the same call).

• Kaching pricing display broken on Gummies Tea pre-lander - found and reported via Discord screenshot to Tomide

"Gummy's tea is getting cooked, but this date is skewed because we were running it and it didn't have proper pricing on it, literally showing on Ka-ching."Ollie Trott

"I sent Tom a screenshot like, bro, the pricing isn't showing on Kachin."Ollie Trott

Decision: avoid product duplication for tests; duplicate pages with same product/variant IDs, use Kaching for pricing tests

Hardik described the current test process of duplicating the product on the backend to make modifications. Nikita said not to duplicate products (creates supplier/backend complexity and extra SKUs); instead keep the same product ID and variant ID but use different pages. For a genuinely new offer they could use Kaching Bundles to modify pricing ('Kaching bundles is good for a bit... they actually have good data to test pricing'), pending developer confirmation. Method: caveman A/B (page A/page B, variant A/variant B, no redirect scripts) to keep CPA data clean. Nikita named 'different selling plans' as one test dimension (alongside pricing, slide images). Ollie reinforced one PDP per SKU. Confirms Nuora runs two products: Gummy and Gut Capsule.

• Decision: stop duplicating products for tests; duplicate pages with same product/variant IDs instead
• Kaching Bundles considered for new-offer pricing tests (planning)
• selling plans named as a test dimension (planning)

"You can have the same product ID, the same variants ID, but different pages."Nikita Lienov

"For new offer, can we use kaching bundles to modify the pricing? ... Kaching bundles is good for a bit. For some reason, they actually have good data to test pricing, but it depends."Nikita Lienov

"we only have one PDP to focus on per skew."Ollie Trott

Tomide removed and replaced by new developer Aman across Discord/Replo/ClickUp

On the call Hardik and Nikita agreed to remove Tomide (previous Nuora developer) from Discord, Replo, and ClickUp, citing slow execution and repeated misses on small details. Nikita confirmed he removed Tomide from Replo. They onboarded new developer Aman (A-M-A-N), ~32,000 Upwork hours, prior PDP work for Happy Mammoth, paid via Contra time tracker, confirmed active on the Shopify store. The dev handover context for who will execute future subscription/SKU and Kaching fixes. Claude later edited the Nuora Team Roles memory file to record Tomide removed (May 5, slow execution) and replaced by Aman.

• Removed Tomide from Discord/Replo/ClickUp; onboarded Aman (active on Shopify store)
• Memory edit: dev role change Tomide -> Aman

Subscription-cadence A/B test plan: Gut Capsule control vs new 'subscription take rate' Gut Offer; gut-offer-3 high CPA

Hardik described a planned A/B test putting /products/gut-capsule in the control and the new 'Gut Offer' (the 100% subscription take-rate offer, getting rid of the bottle/adding the tin) in the variant, and asked how to pick proven ads without the ad becoming a confounding variable. Nikita's answer: the chosen ad is a constant (proven top-of-funnel Gut Capsule winners, e.g. ad B0221/B0243/B0298), not a variable. Hardik reported three tests done with the gut offer: the first two ran on the 'alleyway' tool (Elevate) and data was completely flawed because, despite no one-time option, it showed purchasers as one-time-only buyers; 'gut offer three' (SKU 9148537176204, page gut-offer-3) was being tested inside the AI ads maker A/B test tool and was showing high CPA. The subscription-offer-test thread that sits on top of the subscription restructure.

• A/B test setup: Gut Capsule (control) vs Gut Offer / new subscription take rate (variation); Gut Offer 3 tested in AI ads maker tool

"Three tests have been done with the gut offer. First two were on the alleyway tend, data was completely flawed... it was showing that people who purchased were the people who had one timer only."Hardik Dewra

May 5 call: add-to-cart vs purchase ratio breakage diagnosis (checkout friction)

Nikita diagnosed that cost-per-add-to-cart should be roughly 2 to 2.5x lower than CPA; when CPA is much higher than 2.5x the add-to-cart cost, there is 'some sort of breakage' or friction in the cart or checkout. He pointed to an ad with $16 cost-per-add-to-cart that should have produced a ~$35-39 CPA but didn't, indicating funnel breakage after add-to-cart. Relevant to the 'subscribed by accident' checkout UX problem.

"If your cost per purchase is higher, there's something, there's some sort of friction, something wrong with the card or something wrong with the checkout."Nikita

Claude decoded the Nuora 'Updated Master sheet.xlsx' SKU/variant migration map

In a May 7 Claude Code session, Claude loaded /Users/hardikdewra/Downloads/Updated Master sheet.xlsx (4 sheets) with openpyxl and dumped the SKU/variant structure (only rows 1-15 per sheet were read, so per-SKU coverage is partial). Sheet1 holds old/already-migrated SKUs and Sheet2 holds current live SKUs, both with columns: internal SKU name, description, SKU Product ID, Variant ID, Ideal Cadence, Quantity Shown in Cart, Quantity Sent to Customer, OTP price, Subscription price, Selling Plan Attached, and Skio active-subscriber count (blank for almost every row except the old gummies SKU). Migration status per SKU (Done with Migration / Already Migrated Correct Cadence / We are Migrating it (variable quantities) / Deleted Variant). The Old Highest Converting Gummies SKU (product 8105143369868) showed '0 as of 14th March (All Migrated)' active subscribers. Sheet3 lists duplicate/same-name products to keep or remove with Shopify session/ATC/checkout traffic. Sheet4 is a Shopify-analytics table of landing-page paths with Sessions/Add-to-carts/Reached-checkout (e.g. /products/feminine-balance-gummies-1 = 406,018 sessions, /products/gummies = 166,607, /products/gut-capsule = 47,660).

• openpyxl dump of Updated Master sheet.xlsx (Skio/SKU migration map)

Master sheet Sheet3 product-duplication audit: which same-name products to KEEP vs DISABLE, with Shopify traffic

Sheet3 ('PRODUCT DUPLICATION / SAME NAME PRODUCTS WITH THEIR URL') is the dedup decision table. KEEP ON SHOP: feminine-balance-gummies-1 (9142452486284), Enabled, 406,018 sessions / 23,765 ATC / 19,303 checkout (the live gummies winner). High-traffic Enabled: /products/gut-capsule (9142568321164), 47,660 sessions / 4,572 ATC / 3,524 checkout (the live gut winner). Disabled duplicates to clean up: gut-capsule-r (8400072802444), 11,021 sessions, marked Duplicate; feminine-balance-gummies-2 (9110934093964), 12,525; feminine-balance-gummies-1-r (8974140440716), 14,072. Testing/Disabled: 'Nuora Gut Ritual' product 9169360748684 (template gut-capsule-pdp, Already Disabled, 0 traffic). gut-offer-3 (9148537176204) = Duplicate/Disabled, 310 sessions. Answers which Gut Capsule product is the live winner: 9142568321164.

Claude decoded the Nuora Purchase Friction Report (post-purchase survey Jan 1 - May 3 2026); 9,822 responses

Claude extracted /Users/hardikdewra/Downloads/Nuora Purchase Friction Report.html, built from Nikita's source CSV Gut_Capsules_Post_Purchase_Survey_2026-01-01_to_2026-05-03.csv. The report coded 9,822 website-friction responses into two clusters with 40 verbatim quotes. The 'Buying-flow instability' cluster (326 combined responses) is direct subscription/cart/checkout fallout: 133 navigation/find/link confusion, 113 price/deal/discount/guarantee confusion, 95 technical checkout/payment/cart issues. Verbatim quotes describe the cart showing '1 item' when 3 bottles were ordered, unchecking the auto-renew box silently bumping the order to the more expensive 3-bundle, confusion over whether the subscription stays the same price or jumps (e.g. 'stay $69 or go to $195'), inability to edit the cart, and trouble stopping reorders. The other cluster (313 responses) covers product-verification friction (dosage, ingredient amounts, back-of-bottle/supply). Customer names redacted per PII rule.

"when you order the three bottles, it would be nice for it to say three bottles in the cart. It currently says one item. That is a bit confusing."a customer (survey verbatim)

"After I clicked that I wanted the 2 bundle deal, I unchecked the box for the auto renew and it changed my order to the more expensive 3 bundle deal. I had to take it out of my cart and redo it."a customer (survey verbatim)

"I couldn't find a clear enough description for how much a subscription would cost after the initial purchase. Would it still be $69 the next time I'd get billed or would it be $195?"a customer (survey verbatim)

Cart-bug and subscription-clarity fixes mapped into landing-page spec from friction data

After decoding the friction report, Claude summarized the buying-flow fixes and wrote them into the LP spec /Users/hardikdewra/Documents/Cursor Projects/Nuora Offer Tests/Landing Pages/nuora-opositiv-style-v1.md: flagged 'Cart bug Olli mentioned - unchecking sub bumps to 3-bundle, kills trust', a single locked subscription price ('$X locked for life of subscription'), a single guarantee everywhere (some pages say 30-day, some 60-day), and a FAQ answering whether the subscription price stays the same after the first order. Checkout errors (95 mentions) noted as a dev fix not a landing-page fix. Aftermath remediation planning, not an executed Skio/Shopify operation.

• LP spec authored: nuora-opositiv-style-v1.md with subscription/cart friction fixes

Claude confirmed live Gut Ritual / Vaginal Probiotic variant IDs / subscription pricing from product JSON

To ground landing-page copy, Claude read /Users/hardikdewra/Documents/Cursor Projects/nuora-offer-engine/data/products/gut_ritual.json and vaginal_probiotic.json (both scraped 2026-03-15). gut_ritual.json confirmed Gut Ritual OTP variant IDs/prices: 1 bottle 45566109024396 at $59, 2 bottles 45566109057164 at $69, 3 bottles 45566109089932 at $79 (handle gut-capsule). The gut SUBSCRIPTION prices ($49/$59/$69 for 1/2/3 bottle) come from the master sheet, not this JSON. vaginal_probiotic.json (handle feminine-balance-gummies-1) confirmed OTP $40.99/$57.99/$68.99 and subscription $34.99 monthly / $49.99 every 2 months / $58.99 every 3 months, but contains NO variant IDs. Confirms the post-migration 1/2/3-month subscription cadence structure with matching ship quantities.

Claude updated Nuora team memory: Tomide removed, Aman is new dev

In the May 7 session, after the call paste, Claude edited the Nuora Team Roles memory file to record Tomide removed (May 5 2026, slow execution / repeated detail misses) and replaced by Aman (~32k Upwork hours, ex-Happy Mammoth, paid via Contra time tracker). It also added Kira (creative/visual ideas) and Ollie (media buyer). The dev change is the operationally relevant fact for the SKU/Skio handover.

• Memory edit: dev role change Tomide -> Aman