PostHog

Adaptyはサブスクリプションイベント（購入、更新、返金、トライアル開始など）をPostHogのイベントストリームに送信できるため、既存のデータと一元管理できます。

各イベントには収益、通貨、ストア、プロダクトの詳細に加え、購入を生み出したペイウォールとA/Bテストのバリアントが含まれます。データが届けば、PostHogのあらゆるツールからこの情報を活用できます。

AdaptyのサブスクリプションイベントをPostHogに連携することで、既存のトラッキングデータに収益の次元が加わります。

• どのアプリ内アクションがサブスクリプションにつながるか？ 独自のPostHogイベントとtrial_started・subscription_startedを照合して、購入につながる行動を特定しましょう。
• どの実験バリアントが収益を上げたか？ プロダクトの変更に関するPostHog実験の指標として、Adaptyの収益イベントを活用しましょう。AdaptyのA/B テストはペイウォールとオンボーディングをカバーしています。
• 返金の前に何が起きているか？ subscription_refundedでインサイトを作成し、該当するユーザーを開いてセッション録画を確認しましょう。
• バグが更新に影響しているか？ エラートラッキングとsubscription_renewal_cancelledをクロスリファレンスしましょう。このイベントはユーザーが自動更新をオフにした時点で即座に発火するため、subscription_expiredよりずっと早く検知できます。
• サブスクライバーと無料ユーザーの継続率を比較する 派生したアクセスステータスをもとにコホートと継続率カーブを作成しましょう。詳しくはサブスクライバーと無料ユーザーを見分ける方法をご覧ください。
• どのペイウォールとバリアントが収益を生んだか？ 購入イベントにはそれを生んだペイウォールとバリアントの情報が含まれているため、ペイウォール別に収益を分析できます。PostHogのSDKでペイウォール表示を計測し、表示から購入までのコンバージョンを一緒に追いましょう。
• 両方のデータセットにまたがって質問する にはインサイトまたはSQLを使いましょう。

インテグレーションの仕組み

PostHog では、各ユーザーを distinct_id という文字列で識別します。このインテグレーション全体は、Adapty と PostHog が同じ文字列を共有することで成り立っています。

1. PostHog SDKは、ユーザーにdistinct_idを割り当てます。初回起動時、この文字列はデバイス単位の匿名IDです。ログイン時にカスタム値を設定したり、ログアウト時にリセットしたりすることもできます。
2. アプリ起動のたびに、Adapty.activate()の後、購入処理が発生する前に、setIntegrationIdentifier()を使ってdistinct_idをAdaptyに渡します。AdaptyはこのをユーザーのAdaptyプロファイルにposthog_distinct_user_idとして紐付けます。
3. ユーザーがトライアルを開始するか購入を行うと、Adaptyのサーバーがそのdistinct_idを付加してPostHogのCapture APIにイベントをPOSTします。このやり取りはサーバー間で行われ、アプリの外部で完結します。
4. PostHogはそのイベントをdistinct_idを持つユーザーに紐付けるため、サブスクリプションの売上がアプリ内でそのユーザーが行った他のアクティビティと並んで表示されます。

Adapty のIDをPostHogのIDに合わせる

両システムが同じ distinct_id を使用しないと、1人のユーザーが2つの独立したエンティティに分かれてしまいます。これを防ぐ方法は2つあり、どちらを選ぶかは購入が発生するタイミングによって異なります。

購入にログインが必要な場合、ユーザーがログインした時点でPostHogの identify() をCustomer User IDと共に呼び出してください。Adapty は他に値がない場合にその値を使用するため、両システムで一致します。

匿名ユーザーが購入できる場合、PostHog の distinct_id を読み取り、setIntegrationIdentifier で Adapty に渡してください。Adapty.activate() の後の毎回の起動時、および PostHog の reset() のたびに呼び出してください。匿名プロファイルには Customer User ID がないため、PostHog 自身の ID が両システムで共有できる唯一の値です。詳細はアプリコードを設定するを参照してください。

どちらの方法を選んでも、その値はアプリの再インストール後も保持される必要があります。Adapty は再インストールのたびに新しいプロファイルを作成し、PostHog もデバイスごとに新しい匿名 distinct_id を生成するため、どちらのシステムも単独ではインストールをまたいだ ID の引き継ぎを行いません。Adapty は匿名プロファイル間で有料アクセスを引き継ぎますが、これはアクセスレベルを紐付けるものであり、アナリティクス上の ID を紐付けるものではありません。引き継いだプロファイルは依然として自身の ID でイベントを送信します。バックエンドが管理する安定した ID がなければ、再インストールを行ったサブスクライバーは PostHog 上で「更新はあるが購入履歴のない新規ユーザー」として表示されてしまいます。

IDの不一致はデータの断片化を引き起こします。詳細は1人のユーザーが複数の人物として表示されるを参照してください。

セットアップ手順

PostHog プロジェクトトークンをコピーする

1. データをホストしているデプロイメント（US Cloud または EU Cloud）にサインインし、接続したいプロジェクトを選択します。

2. Settings > Project > General に移動し、Project token & ID セクションを見つけます。

   

3. Project token をコピーします。phc_ から始まります。PostHog はこれを書き込み専用かつ公開しても安全なものとして説明しているため、ローテーションする必要はありません。

Adapty を設定する

1. Adapty ダッシュボードで Integrations > PostHog を開きます。

2. PostHog トグルを有効にします。

3. トークンを Project API key に貼り付けます。Adapty は保存時に PostHog に対してトークンを検証します。トークンが無効な場合は、イベントを無音で破棄するのではなく、即座にエラーになります。

4. 「サーバーの場所」セクションはご利用の設定によって異なります。

• PostHog Cloud を使用する場合は、サインインしたデプロイメントに合わせて Region を US Cloud または EU Cloud に設定してください。PostHog Instance URL フィールドは空のままにしてください。
  • 自前のインスタンスを運用している場合は、Self-hosted を選択し、PostHog Instance URL フィールドに入力してください。Region は選択しないでください。Adapty がプロキシや VPN なしでそのインスタンスに到達できる必要があります。

5. How the revenue data should be send で、Adapty が送信する収益データの種類を選択します。3つのオプションは Adapty アナリティクスの収益表示 に対応しているため、選択した内容が PostHog の数値と一致する表示になります。

6. 残りのオプションを設定します：

7. Events names セクションで個々のイベントの名前を変更したり、無効にしたりします。PostHog は空でないイベント名であれば何でも受け付けるため、既存のタクソノミーに合わせた名前を使用してください。

8. Save をクリックします。

サンドボックスデータを本番環境から分離する

Adaptyはサンドボックスと本番のトランザクションを同じインテグレーション経由で送信するため、どちらも同じPostHogプロジェクトに届きます。このインテグレーションは Project API key を1つ使用し、別のサンドボックス用キーを別の送信先に指定する仕組みはありません。

開発ビルドに専用のPostHogプロジェクトを用意しても、本番プロジェクトへのサンドボックスイベントの混入は防げません。サンドボックスかどうかはストアのトランザクションに紐づくプロパティであり、ビルドの種類には依存しないからです。App Storeの審査やTestFlightでの購入は、本番ビルドから行われるサンドボックストランザクションです。

代わりに、クエリで両者を区別しましょう。すべてのイベントには environment プロパティが含まれており、値は Sandbox または Production に設定されています。実際の収益のみを抽出するには次のフィルターを使用します：

WHERE properties.environment = 'Production'

アプリのコードを設定する

1. PostHog の SDK から現在の distinct_id を取得します:

   • アプリの起動ごとに、Adapty.activate() の後、かつ購入が発生する前に行ってください。これより前のイベントは PostHog によって別のユーザーに紐付けられてしまいます。
   • PostHog の reset() の後に行ってください。ほとんどのアプリはログアウト時に reset() を呼び出します。reset() は新しい匿名 ID を生成し、前のユーザーとは紐付けられないため、古い値を使い続けるとログアウトしたユーザーを指し続けてしまいます。

2. setIntegrationIdentifier() を使って Adapty に渡します。

let distinctId = PostHogSDK.shared.getDistinctId()

do {
    try await Adapty.setIntegrationIdentifier(.posthogDistinctUserId(distinctId))
} catch {
    // handle the error
}

Adapty.setIntegrationIdentifier(
    AdaptyIntegrationIdentifier.posthogDistinctUserId(PostHog.distinctId())
) { error ->
    if (error != null) {
        // handle the error
    }
}

Adapty.setIntegrationIdentifier(
    AdaptyIntegrationIdentifier.posthogDistinctUserId(PostHog.distinctId()),
    error -> {
        if (error != null) {
            // handle the error
        }
    }
);

try {
    final distinctId = await Posthog().getDistinctId();

    await Adapty().setIntegrationIdentifier(
        key: "posthog_distinct_user_id",
        value: distinctId,
    );
} on AdaptyError catch (adaptyError) {
    // handle the error
} catch (e) {
    // handle the error
}

const posthog = usePostHog();

try {
    await adapty.setIntegrationIdentifier(
        "posthog_distinct_user_id",
        posthog.getDistinctId()
    );
} catch (error) {
    // handle `AdaptyError`
}

インテグレーションを確認する

1. サンドボックス購入をトリガーし、Adapty ダッシュボードの Event Feed を開きます。各配信試行はその結果とともに表示されます。Adapty は保存時に Project API key とインスタンス URL を検証するため、この段階での失敗はまれです。よくある原因は以下のとおりです：

   • 機能しなくなったキー。 インテグレーションキーを削除すると、PostHog は 401 を返します。
   • 応答しなくなったインスタンス。 Adapty は 10 秒後に待機を停止します。セルフホスト環境に影響する場合があります。

   失敗したイベントにカーソルを合わせると、PostHog のレスポンスを確認できます。

2. PostHogでActivityビューを開き、イベントを確認します。購入のenvironmentプロパティがSandboxになっているはずです。

3. そのユーザーのプロファイルを開き、Distinct IDsタブを確認します。アプリ自身のイベントとAdaptyのサーバーイベントが同一ユーザーに紐づいているはずです。同じユーザーに対して2人分の別ユーザーが表示されている場合、IDが一致していません。1人のユーザーが複数のユーザーとして表示されるを参照してください。

PostHog での収益レポート

Adapty Analytics は収益データの信頼できる唯一の情報源であり続けます。これは、このインテグレーションが転送するデータのみを受け取る PostHog とは異なり、ストアの完全なデータをもとに計算するためです。PostHog のダッシュボードでプロダクト指標と並べて収益も確認したい場合は、PostHog の Revenue Analytics が指定したイベントプロパティから収益を読み取ります。PostHog で Data management > Revenue を開き、次のようにマッピングしてください。

PostHog の「values are in cents」オプションは オフ のままにしてください。Adapty は小数点形式の金額を送信します（最小単位ではありません）。

PostHog イベント構造

Adapty は、PostHog インテグレーションページ の Events names セクションで有効にしたイベントを、イベントごとに 1 件のキャプチャリクエストとして送信します。

{
  "api_key": "phc_YOUR_PROJECT_TOKEN",
  "distinct_id": "john.doe@example.com",
  "timestamp": "2026-01-08T11:06:12+00:00",
  "event": "subscription_started",
  "properties": {
    "$ip": "10.168.1.1",
    "$geoip_time_zone": "America/New_York",
    "$geoip_disable": true,
    "$set": {
      "email": "user@example.com",
      "first_name": "John",
      "last_name": "Doe",
      "birthday": "1990-01-01",
      "gender": "male",
      "os": "iOS"
    },
    "*": "{{other_event_properties}}"
  }
}

Webhookのみの5つのプロパティはここには表示されません。制限事項をご覧ください。

Distinct ID の優先順位

Adapty は最初に検出した値を使用します：

Adapty はこの優先順位をユーザー単位ではなく、イベント単位で評価します。setIntegrationIdentifier の呼び出し前に発生したイベントは優先度の低い ID に紐付けられ、PostHog は同一ユーザーに対して別の人物として記録します。

Adapty の ID を PostHog に合わせるの2つの設定のいずれかを選択し、イベントが送信される前に値を設定してください。すでに分裂してしまったユーザーについては、1人のユーザーが複数のユーザーとして表示されるを参照してください。

IPと位置情報のプロパティ

Adaptyのイベントを位置情報でセグメントするには、store_countryおよびprofile_countryプロパティを使用してください。AdapityはPostHogの位置情報ルックアップを無効化するため、PostHogは独自の$geoip_*値を追加しません。以下の3つのプロパティはイベントごとに適用されるため、プロジェクトの設定や独自のイベントには影響しません。

Personプロパティ

$set 内のすべての項目は、イベントプロパティではなくPostHogのpersonプロパティになります。PostHogはpersonプロパティを個々のイベントではなくユーザー自体に紐付けるため、特定の瞬間ではなくユーザーの現在の状態を表します。Adaptyは値のないフィールドを省略し、すべてのフィールドに値がない場合は$setごと除外します。

制限事項

• アクセスレベルやサブスクリプションステータスは含まれません。 access_level_updated イベントはwebhookインテグレーション専用であるため、AdaptyはPostHogにユーザーの現在のアクセス権を示すフィールドを送信しません。詳しくはサブスクライバーと無料ユーザーを見分ける方法をご覧ください。
• 過去データのバックフィルには対応していません。 Adaptyはインテグレーションを有効にした時点以降のイベントのみを転送します。それ以前の購入はPostHogに届きません。
• PostHogはAdaptyイベントをジオタグしません。 PostHogはイベントの送信元IPアドレスから位置情報を推測します。Adaptyイベントの送信元は常にAdaptyのサーバーであり、ユーザーのデバイスではありません。データの汚染を防ぐため、AdaptyはPostHogにこのルックアップをスキップするよう指示します。Adaptyは$geoip_time_zone、store_country、profile_countryを設定しますが、より詳細な位置情報は提供されません。
• ソースでAdaptyイベントをフィルタリングすることはできません。 PostHogは送信元SDKを$lib（posthog-ios、posthog-android、webなど）に記録しますが、AdaptyはSDKを介さずPostHogのAPIに直接投稿するため、このプロパティは空のままになります。代わりにイベント名でフィルタリングしてください。

トラブルシューティング

• イベントがPostHogに表示されない
• access_level_updatedがイベントフィードで失敗として表示される
• 1人のユーザーがPostHogで複数の人物として表示される
• PostHogの収益がAdatyアナリティクスと一致しない
• イベントが発生前にPostHogに表示される
• Adaptyイベントに国・都市データがない
• サブスクライバーと無料ユーザーを区別する方法
• ペイウォールのビューがPostHogに表示されない

PostHogにイベントが表示されない

• まず Adapty の Event Feed を確認してください。配信失敗の場合、PostHog が返したエラーが表示されます。
• 配信成功は、PostHog がイベントを保持したことを保証しません。PostHog はペイロードとキーが有効であれば 200 OK を返しますが、名前がないイベントや distinct_id が空のイベントは黙って破棄されます。
• お探しのイベントがインテグレーション設定で有効になっているか確認してください。
• PostHog をセルフホストしている場合、サーバーが /capture への Adapty の POST リクエストを受け付けるよう設定されているか確認してください。設定が成功していても、このアクセスが存在するとは限りません。Adapty はキーの有効性確認に別のエンドポイントを使用します。

access_level_updated がイベントフィードで失敗として表示される

access_level_updated は webhook 専用イベントです。Adapty はこのインテグレーションにこのイベントを送信しません。ただし、Adapty は有効なすべてのインテグレーションに対して結果を記録するため、サポートされていないイベントは失敗として表示されます。

1人のユーザーがPostHogで複数の人物として表示される

PostHogはほとんどの分割を後から元に戻すことができません。詳しくはAdaptyのIDをPostHogに合わせるをご覧ください。

IDが異なる理由

Adaptyが送信する各イベントには、ユーザーのAdaptyプロファイルからのdistinct_idが含まれています。詳細はDistinct ID の優先順位を参照してください。Adaptyはイベントを送信するタイミングでその値を読み取ります。アプリがsetIntegrationIdentifierを呼び出したタイミングではありません。AdaptyイベントのDistinct IDがアプリインストールの内部Distinct IDと異なる場合、PostHogは2種類のイベントを別々のユーザーとして扱います。

不一致が発生する原因は3つあります。

1. いずれかのプラットフォームでアプリが setIntegrationIdentifier を呼び出していない。 Adapty はカスタマーユーザー ID または匿名プロファイル ID にフォールバックします。リリース対象のすべてのプラットフォームを確認してください。
2. setIntegrationIdentifier の呼び出しが遅すぎる。 呼び出し前に発生したサブスクリプションイベントにはフォールバック ID が付与されます。
3. PostHog に identify() で送る ID と、インテグレーション識別子として設定した ID が異なる。 Adapty は最後に渡された値を保持し、自動的には更新しません。PostHog の reset() は新しい匿名 ID を割り当てますが、Adapty は以前の ID を保持したままになります。そのため、reset() を呼び出すたびに setIntegrationIdentifier を再度呼び出してください。

これら3つすべてを修正すれば、PostHog はその後1人のユーザーにつき1つのプロファイルを記録します。

最初の identify() 呼び出し時に乖離したユーザー ID を統合する

アプリには、乖離した ID を調整できる機会が一度だけあります。それが PostHog の identify() への最初の呼び出しです。PostHog はアプリインストールのイベントをその呼び出しで指定したプロファイルに統合するため、Adapty が送信する ID を指定してください。詳細は Adapty の ID を PostHog に合わせる を参照してください。この呼び出し以降、PostHog はアプリインストールを識別済みとして扱い、識別済みの2人のプロファイルを統合することを拒否します。

拒否された統合を確認する

PostHogが1人のユーザーを2人として記録したことを確認するには、PostHogでData management > Ingestion warningsを開き、Refused to merge an already identified userエラーを探してください。

PostHogはIDが予約済みの値である場合もマージをブロックします。予約済みの値の一覧については、AdaptyのIDをPostHogのIDに合わせるを参照してください。

既存の分割を修復する

identify() も alias() も、マージウィンドウが閉じた後にスプリットを修復することはできません。強制的にマージするには PostHog の $merge_dangerously のみが使えます。PostHog はこれを「不可逆であり、セーフガードなし、実装上の問題からの一度限りの復旧手段」として文書化しています。

設定ではなくイベントとして送信し、2つのpersonを指定します。どちらが残るかは方向性によって決まります：

送信前に、どちら側を残すか決めておきましょう。Adapty のユーザーはサブスクリプション履歴を持ち、アプリ側のユーザーはアプリ内行動のデータを持っています。まず1人のユーザーで試して結果を確認してから、一括修正を行ってください。各 SDK のペイロードについては PostHog の How to merge users を参照してください。

PostHog の売上が Adapty アナリティクスと一致しない

Adapty と PostHog は同じイベントを異なる方法で処理します。この違いが、ほぼすべての不一致の原因です。

• すべての Adapty イベントには 3 種類の売上金額が含まれており、それぞれ 収益データの送信方法 の各オプションに対応しています。 PostHog のプロパティとの対応は以下のとおりです。

行を比較すると、手数料、税金、またはその両方に相当する差額が生じます。Report user’s currency の設定にかかわらず、Adapty はすべてのイベントで6つのプロパティをすべて送信します。

• Adaptyは期間内のすべての収益イベントをカウントしますが、PostHogのインサイトは追加したイベントのみをカウントします。 subscription_renewedを省略すると、定着したアプリの収益の大部分が失われます。

• Adaptyの日付範囲は最終日全体をカバーしますが、timestampフィルターは指定した時点で止まります。 Adaptyの7月1日〜7月15日は、7月15日23:59:59までのすべてのイベントを含みます。PostHogでは、timestamp < 2026-07-15とするとその日全体が除外されるため、timestamp < 2026-07-16を使用してください。

• Adapty Analytics はサンドボックスと本番を分けて管理しますが、PostHog では混在します。 properties.environment = 'Production' でフィルタリングしてください — サンドボックスデータを本番から除外するを参照。

• Adapty はアプリのレポートタイムゾーンを使用しますが、PostHog は UTC で受信します。 App Settings でどのタイムゾーンを設定していても、インテグレーションは常に UTC タイムスタンプを受け取ります。たとえば、7月1日 23:30 UTC の購入は、レポートタイムゾーンが +02:00 の場合、Adapty では 7月2日として記録されますが、PostHog では 7月1日のままになります。

• PostHog に過去のイベントが表示されない。 過去のイベントが届かない理由は2つの制限によるもので、それ以前のサブスクリプションや更新のイベントは Adapty Analytics にのみ記録されます。PostHog の SDK で独自に取得したイベントには影響しません。

• Exclude historical events（履歴イベントを除外）は、PostHogインテグレーションページのトグルで、デフォルトでオンになっています。Adaptyはプロファイルが存在する前の日付のイベントを送信せず、イベントフィードでは各イベントに有効期限切れのフラグが付きます。そのため、ユーザーのAdaptyイベントはAdaptyビルドの初回起動から始まります。オフにすると、それ以降の過去日付のイベントも通過させることができます。

  • 履歴データのバックフィルなしは恒久的な制限事項です。Adaptyはイベントを処理した時点で送信し、インテグレーションを有効化する前に処理したイベントに遡って対応することはありません。

• インテグレーション設定で無効にしたイベントはPostHogに送信されません。 Adapty Analyticsでは引き続きカウントされます。Adaptlyの設定のEvents namesセクションを確認してください。

イベントが発生前にPostHogに表示される

更新やトライアルのコンバージョンについては、Appleはイベント発生前にAdaptyへ通知を送ります。Adaptyはこれらのイベントを、将来のtimestampをそのままにして即座に転送します。Adapty Analyticsはその時刻が過ぎるまでイベントを保留するため、PostHogにはAdaptyがまだ報告していないイベントが表示されることがあります。どちらの動作も正しいものです。timestampでフィルタリングして除外するには、将来の日付を持つイベントのタイムスタンプを参照してください。

Adaptyイベントに国・都市データがない

代わりに store_country と profile_country プロパティを使用してください。PostHog 独自の $geoip_* の値は Adapty イベントでは空になります。詳細は IP とロケーションプロパティ を参照してください。

有料ユーザーと無料ユーザーを見分けるには

Adapty のイベントレポートには、ユーザーの現在のアクセス状態は含まれません。$set に含まれるのは email、first_name、last_name、birthday、gender、os のみです。アクセスレベルを説明するイベントプロパティは access_level_updated でのみ設定されますが、Adapty はそのイベントを Webhook 連携にのみ共有します。

解決策は 2 つあります。

• PostHog 内のステータスはイベント履歴から導き出してください。直近の Adapty イベントが subscription_started、subscription_renewed、または trial_converted であるユーザーは現在アクセス権を持っており、直近のイベントが subscription_expired、trial_expired、または subscription_refunded であるユーザーはアクセス権を持っていません。
• webhook インテグレーション を使用して access_level_updated を受信し、自分で PostHog に転送してください。PostHog のキャプチャ API は独自のペイロード形式を期待しているため、変換ステップが必要です — Adapty の webhook ペイロードをそのまま PostHog に送信することはできません。

ペイウォールのビューがPostHogに表示されない

AdaptyのSDKは、ペイウォール、フロー、オンボーディングのインタラクションをAdapty Analytics専用に記録します。Adaptyのサーバーはサブスクリプションイベントのみをインテグレーションに転送するため、これらのインタラクションはサブスクリプションイベントには含まれません。Webhookにも含まれません。ペイウォールを表示している箇所でPostHogのSDKを使って直接取得してください。