spending-analysis

要件

• pollinations リポジトリのルートから実行します。
• jq と sops をインストールします。
• enter.pollinations.ai/observability/scripts/tb-prod.sh "<sql>"（以下、tb-prod.sh と表記）でクエリを実行します。これは SOPS から本番環境の読み取りトークンを使用します。ステージングワークスペースには実際の収益データはありません。
• クエリ出力をパイプに渡す前に set -o pipefail を有効にし、クエリの失敗がパイプライン全体の失敗として扱われるようにします。

収益のクエリでは、非同期決済手段が正確に 1 回だけカウントされるよう、Stripe チェックアウトの成功イベントで絞り込む必要があります。

週ごとのパック収益

tb-prod.sh "SELECT toStartOfWeek(timestamp) AS week, round(sum(amount_cents) / 100, 2) AS revenue_usd, count() AS purchases FROM stripe_event WHERE payment_status = 'paid' AND event_type IN ('checkout.session.completed', 'checkout.session.async_payment_succeeded') AND timestamp >= now() - INTERVAL 90 DAY GROUP BY week ORDER BY week DESC FORMAT JSON" | jq '.data'

最近のパック購入

tb-prod.sh "SELECT timestamp, user_id, session_id, amount_cents / 100 AS amount, currency, payment_method FROM stripe_event WHERE payment_status = 'paid' AND event_type IN ('checkout.session.completed', 'checkout.session.async_payment_succeeded') ORDER BY timestamp DESC LIMIT 100 FORMAT JSON" | jq '.data'

顧客別の収益

tb-prod.sh "SELECT user_id, round(sum(amount_cents) / 100, 2) AS revenue_usd, count() AS purchases FROM stripe_event WHERE payment_status = 'paid' AND event_type IN ('checkout.session.completed', 'checkout.session.async_payment_succeeded') AND timestamp >= now() - INTERVAL 30 DAY GROUP BY user_id ORDER BY revenue_usd DESC LIMIT 50 FORMAT JSON" | jq '.data'

残高バケット別の週ごとの利用額

tb-prod.sh "SELECT toStartOfWeek(start_time) AS week, splitByChar(':', selected_meter_slug)[-1] AS meter_source, sum(total_price) AS total_spend, count() AS requests FROM generation_event_v2 WHERE start_time >= now() - INTERVAL 60 DAY AND environment = 'production' GROUP BY week, meter_source ORDER BY week DESC FORMAT JSON" | jq '.data'

資金の出所と支出先

generation_event_v2 の支出データ（pack_spend、selected_meter_slug）は、どのバケットが消費されたかを示すもので、資金の出所を示すものではありません。pack_balance には Stripe 購入と自動チャージによるクレジットが加算されますが、BYOP マークアップ、コミュニティモデルの報酬（支払者のバケットに支払われます。shared/billing/track-helpers.ts）、一部のクエスト報酬によるクレジットも含まれます。そのため、パック支出 ≠ 現金です。また、Stripe チェックアウトの行だけでは自動チャージを把握できません。自動チャージでは checkout.session.* イベントが生成されないためです。現金による資金と獲得した資金を区別するには、各資金源を個別に照合し、金額の基準が異なる数値を合算しないでください。

• Stripe チェックアウトの pollen_credited（stripe_event、payment_status = 'paid'）
• 自動チャージの amount_usd（クレジットされた元本。以下を参照）
• 過去の Polar クレジット（2025 年 11 月～2026 年 1 月）
• バケット別のコミュニティ／BYOP 報酬の獲得分

現金購入がないことは、未払いまたは不正行為を意味するものではありません。パック支出も現金による支払いの証拠にはなりません。

自動チャージ：元本と総支払額

D1 の自動チャージの amount_usd は、クレジットされた Pollen の元本です。Stripe の手数料と税金はその上に加算されます。総現金額は Tinybird の stripe_event にある payment_intent.succeeded の行で確認できます。これらの行では user_id が空です（自動チャージはここではユーザーに紐付けられません）。ユーザーごとに stripe_invoice_id を使って請求書を取得し、amount_paid を使用してください。元本、総支払額、税金、返金、純収益は、それぞれ別の数値として扱ってください。

過去の価格変更

過去の価格変更は、PR のタイトルや告知ではなく、当時デプロイされていたコードから特定してください。「X％安くなる」という告知と同日に、相殺する倍率変更が行われている場合があります。generation_event_v2 で請求された単価を確認してください。

tb-prod.sh "SELECT toDate(start_time) AS day, round(avg(total_price), 6) AS avg_unit_price, count() AS requests FROM generation_event_v2 WHERE model_used = '<model>' AND start_time BETWEEN '<before>' AND '<after>' GROUP BY day ORDER BY day FORMAT JSON" | jq '.data'

プロバイダーのコスト、priceMultiplier によるマークアップ、パッククレジットのプロモーションは、それぞれ独立して変動します。3 つすべてを確認してください。支払われた現金とクレジットされた Pollen は分けて扱ってください。Pollen の割引は、現金の購買力を変えません。説明対象の決済イベントより前に、誰がその変更の影響を受けていたか、また同時に行われた変更があれば、それも記録してください。

コンバージョンコホート分析

「このユーザー群はより多く支払う」または「X がコンバージョンを促した」という主張では、まず比較方法を定義してください。

• 結果を確認する前にコホートを選定します。 決済や、決済を条件とする報酬に基づいて選定しないでください。貢献に対する報酬（PR／クエストのマージ）は問題ありませんが、決済がトリガーとなる報酬は対象外です。
• メンバーシップと決済確認の両方について、基準日を固定します。
• 観測期間を揃えます。 直近 7 日間のコホートがコンバージョンまでに得られる期間は 0～7 日です。同じ方法で測定した別のコホートとだけ比較するか、「登録後の最初の 7 日間」のように、ユーザーごとに固定した期間を使用してください。
• 順序を確認します。 報酬に紐付くコホートでは、報酬の前と後のどちらで決済したかを集計してください。大半が先に決済していたなら、その報酬がコンバージョンを促したとはいえません。
• 各ユーザーは 1 回だけ数えます。
• 割合とともに、グループの人数と注意点を報告します。

メモ

• stripe_eventは、パック購入の収益分析における信頼できる唯一の情報源です。
• generation_event_v2は、現金収益ではなく、Pollenの消費を記録します。
• どちらのデータセットもuser_idを使用しているため、収益と使用状況を直接結合できます。
• ダッシュボードのdaily_stripe_revenueパイプには、同じ有料イベントのフィルターが適用されます。
• 移行前の収益履歴については、Stripe導入前（2025年11月～2026年1月）の販売事業者はPolarであり、現在は廃止されている点に注意してください。重複期間の境界を確認せずに、過去のPolarとStripeの合計を合算しないでください。
• リクエスト数のシェア（BYOPのシェアなど）は無料トラフィックに大きく左右され、急速に変動します。常に対象期間を明記し、戦略的な主張には収益シェア（total_priceの割合）を使用してください。