競合の価格変更に対する公開の反応を調べる

1. 公式情報で価格変更を確認する

ある公開の質問では、調査をする人が料金ページを手作業で確認し、スクリーンショットを撮り、先週から何が変わったかを思い出そうとしていると述べています。ここから得られる実務上の教訓は、記憶に頼らず、日付付きの証拠を残すことです。この公開の質問は背景情報になります。ただし、この方法への需要を測定するものではありません。調査に関する公開の質問：2026年8月1日公開、2026年10月25日取得。調査上の問題についての1件の公開記述を参照してください。

競合の公式発表、料金に関する通知、または日付のある別の公式声明を探します。そのURLと、変更を説明している箇所の原文を保存します。確認した日時も記録します。

次の日付と日時を区別して記録します。

• 発表日：会社が変更の実施を発表した日。
• 適用開始日：記載された変更が適用される日。
• 確認日時：出典を保存または確認した日時。

通知が対象とするプラン、地域、請求期間、顧客層を記録します。出典に記載がない項目は、不明のままにします。新規契約への変更が確認できても、既存契約にも同じ変更が適用されるとは限りません。

通知に複数の適用開始日がある場合は、記載された対象グループから1つを選んで比較します。複数のグループを扱う場合は、グループごとに分けます。開始日が異なる複数の変更を、1つの前後の境界で正確に表すことはできません。

現在の料金ページだけでは、以前の価格や変更日を確認できない場合があります。古いページを保存していない場合、その内容を推測して補ってはいけません。不足している情報として記録します。このガイドには、競合の価格変更に関する公式発表は含まれていません。実際の変更にこの方法を使う前に、その出典を用意する必要があります。

2. 投稿を収集する前に比較条件を決める

価格変更のコホート管理表を作ります。ここでコホートとは、あらかじめ定めた時期と対象の変更に関する基準を満たす投稿の集まりです。顧客であることを確認できた人の集団ではありません。

調査の問いを1つ書きます。例えば、「このプラン変更の適用開始前後で、選んだ公開投稿にはどのような反応が見られるか」です。売上、顧客の継続利用、市場シェアに関する問いとは分けて扱います。

可能な限り、観測期間の長さをそろえます。各期間の開始と終了を正確に記載します。タイムゾーンを統一し、時刻のない日付をどう扱うかも明記します。1件の投稿が両方の期間に入らないように、境界を明確に定めます。

発表の時期を常に確認できるようにします。適用開始日前の期間にも、発表への反応が含まれる場合があります。その期間は、必ずしも人々が変更を知る前ではありません。また、適用開始日後に公開された投稿でも、投稿者が発表を見たことや、新しい価格を支払ったことの証明にはなりません。

調査全体について、次の項目を保存します。

収集中は、この管理表の条件を一定に保ちます。基準を変える場合は理由を記録し、新しい基準で両方の期間を再確認します。

3. Actorで投稿の候補を探す

Actorは、ホスティング環境で動くデータ収集プログラムです。Reddit Search Scraper Actorは、人が確認するための公開投稿の候補を取得します。公式な価格変更の確認や、この比較作業の完了までを代わりに行うものではありません。

提供された証拠では、2026年10月25日に、公開されているデフォルトビルド2.0.6を確認しています。ビルドとは、プログラムの実行用に作成された版です。そこで定義された入力形式は、以下の小規模な入力に対応しています。プログラムを実行しない静的な検証で、この入力が定義された形式に従っていることを確認しました。このレポートのための収集は実行していません。この検証は、実際に利用できること、結果の品質、網羅性を証明するものではありません。デフォルトビルドの証拠：2026年10月25日確認。定義された項目と静的検証のみを参照してください。

{"maxResults":3,"query":"software price increase","sort":"relevance","time":"all"}

最初の入力案として、これを使います。

1. `query`を、競合の名前と対象の価格変更を特定できる語句に置き換えます。使った検索文字列は、そのまま管理表に保存します。
2. 最初の収集確認では、`maxResults`を3に保ちます。これは取得を要求する件数の上限です。使える投稿を3件取得できるという約束ではありません。
3. 検索を広げる前に、返された記録を確認します。少量の確認は記録の評価に役立ちますが、それだけで結論に必要な証拠がそろうわけではありません。
4. 比較する検索では、`sort`と`time`を統一します。変更した場合は記録します。

この例では、`sort`を`relevance`、`time`を`all`に設定しています。対象の変更に対する2つの観測期間は指定していません。確認時に、公開日に基づいて投稿を各期間に割り当てます。関連度順の検索結果は、両方の期間を均等に代表する標本ではありません。

Taskは、Actorの入力設定を保存したものです。Reddit Brand Mention Snapshot Task：2026年10月25日確認。ページの存在のみ確認し、保存設定は未検証を、出発点として使える可能性があります。公開ページには、Task ID `cKrwlcryUm7yGmgkG`が記載されていました。現在保存されている入力と実行時の動作は検証していません。上記のJSON入力案を、そのTaskに保存されている入力として説明してはいけません。

両方の期間について、検索対象として意図したコミュニティの範囲を同じにし、記録します。返された投稿が属するコミュニティも確認します。後で検索文字列を追加して収集する場合は、両方の期間に適用し、その設定を保存します。

4. 出典の項目と自分の確認項目を分けて保存する

見つかった投稿1件は、出典となる記録1件です。確認済みの購入者1人、変更の影響を受ける契約1件、または返信を含む議論全体を表すものではありません。

この方法で使う、定義済みの出典項目を保存します。

これらは定義された項目であり、すべての記録に必要な値がそろう保証ではありません。実際の値を確認します。日付が空欄またはnullの場合は不明です。古い日付として扱ってはいけません。本文がないことは、投稿者に反応がなかったことを意味しません。

公開日時と確認日時を分けて扱います。適用開始日後に初めて収集した投稿でも、公開は適用開始日前かもしれません。公開日が欠けている場合、`observedAt`を使って観測期間を割り当ててはいけません。

出典の項目の横に、自分で確認した内容を記す列を追加します。

Actorは、これらの調査上の判断を提供しません。証拠を読んだ後に、自分で追加します。

公開投稿や公式の公開通知は、所有者だけが閲覧できる記録とは異なります。契約記録、アカウントへの通知、解約記録には、アクセス権限が必要です。この公開情報の検索手順では、それらを取得できません。権限を得て利用する非公開の記録は、公開出典の管理表や、その表に基づく主張と分けて扱います。

5. 反応を分類する前に対象の変更との関連性を確認する

公開時期だけでは不十分です。変更後の投稿でも、過去の値上げ、別のプラン、または費用全般への不満について述べている可能性があります。

文書にした採用基準を使います。記録で確認した変更と投稿内容を結び付けられるだけの文脈を求めます。製品名と「高い」という言葉だけでは、関連性を判断できない場合があります。保存した文章だけで文脈が足りなければ、公開されている元の投稿を開きます。それでも判断できない場合は、その行を保留にします。

採用した各投稿について、記述を実際より強く解釈せず、そのまま反応を記録します。「解約するつもりだ」は意向を示します。解約が完了した証拠にはなりません。「これで私たちのチームの費用が増える」は公開された発言であり、確認済みの請求記録ではありません。価格についての質問は、質問のまま扱ってかまいません。

コードとは、文書化した基準に従って文章に付ける短い分類ラベルです。集計する前に、反応のコードを定義します。各コードの横に、根拠となる箇所を残します。文章から明確に分類できない場合に備え、「不明」も選べるようにします。

記載された条件を残します。年払いへの不満と、月額料金への不満は異なります。既存の契約者には、新規契約者と異なる条件が適用される可能性があります。記載のないプランや顧客の契約状況を補ってはいけません。

投稿が別の製品について述べている場合は、その文脈を残します。ただし、この変更の調査を乗り換え率の分析に変えてはいけません。その問いは、別のガイドである投稿に記載された製品の選択と乗り換え条件を調べるで扱っています。価格への反応だけでは、乗り換えがあったことも、その理由も確認できません。

6. 重複と収集上の問題に対処する

同じ`postId`を複数回取得した場合は、それぞれの記録を結び付けます。別の検索文字列でも見つかったという理由で、同じ投稿を再び数えてはいけません。取得元を説明できるように、収集履歴を保存します。

投稿IDが異なっていても、同じ不満の引用を含む場合があります。これらの出典は保存し、共通する引用に印を付けます。同じ言葉の繰り返しは、別々の顧客体験の証拠ではありません。表現が似ているという理由だけで、異なる投稿を統合してはいけません。

比較する前に、次の問題がないか確認します。

投稿が返されなかったことは、公開された反応がゼロだった証拠にはなりません。同様に、解約を述べた投稿が見つからなかったことも、解約がゼロだった証拠にはなりません。証拠がないことと、観測した値がゼロであることは、別の問いへの答えです。

7. 選んだ投稿を比較し、別の説明の可能性を検討する

採用した投稿を、観測期間ごとに分けて数えます。数を示すたびに単位を明記します。投稿6件は、投稿6件を意味します。6人や、影響を受けた顧客6人を意味するものではありません。

割合を示すときは、全体として使う集団である「分母」を明記します。テーマ別の件数を数えるときは、その比較の対象条件を満たす投稿だけを使います。時期が不確かな投稿、無関係な変更についての投稿、本文を取得できない投稿は、該当する集計の外に分けて見える形で残します。

各期間に現れるテーマや条件は比較できます。件数の横に、根拠となる箇所を残します。一方の期間で収集した投稿が多くても、単純な件数差を顧客の感情や議論の量の変化として扱ってはいけません。

解釈が1つの議論に大きく左右されていないか確認します。1つのRedditスレッドが結果を左右していないか確認するでは、この集計単位に関する別の問題を説明しています。必要に応じて参照しますが、投稿の比較を顧客数の推定に変えてはいけません。

別の説明の可能性も記録します。価格変更の前後に、別の製品変更、障害、販促活動、請求の訂正、または他の出来事への言及がないか、出典を確認します。これらは確認すべき問いであり、そのような出来事が起きたという主張ではありません。

さらに、各投稿者が発表を見たか、新しい価格がその投稿者に適用されたかという2つの不明点を残します。観測期間の長さをそろえても、この不明点はなくなりません。前後の傾向から説明できるのは、選んだ議論の内容です。原因を証明することはできません。

8. 独自の架空例で手順を確認する

この例の内容は、すべて独自に作成した架空のものです。Actorの実行結果、顧客の成果、または実際に観測した企業についての調査結果ではありません。

架空の公式発表の日付は10月3日です。価格変更は10月10日に適用されます。調査者は、同じ検索文字列とコミュニティの範囲を使い、10月3〜9日と10月10〜16日を比較します。各観測期間は7日間です。

両方の観測期間は、発表後にあります。「前」とは、10月10日の適用開始日前という意味です。変更を知る前という意味ではありません。

調査者には、候補となる投稿が9件あります。

計算の単位は投稿の件数です。

• 適用開始前の投稿3件 + 適用開始後の投稿4件 + 日付が不確かな投稿2件 = 候補の投稿9件。
• 候補の投稿9件 − 日付が不確かな投稿2件 = 日付を確認できる投稿7件。
• 日付を確認できる投稿7件 − 過去の別の変更についての投稿1件 = 比較可能で、対象の変更に関連する投稿6件。
• 最終的な比較対象は、適用開始前の投稿3件と適用開始後の投稿3件です。

過去の別の変更についての投稿は、公開日が適用開始後の観測期間内でも除外したままにします。日付が不確かな投稿2件も、時期別のグループには入れません。収集日を使って割り当ててはいけません。

対象条件を満たす投稿6件に記載された反応と条件を比較します。この例には反応の文章がないため、テーマ別の件数や感情の変化を示すことはできません。この例で学べるのは、採用する投稿の件数の計算だけです。

この架空の比較の分母は、日付を確認でき、対象の変更に関連する投稿6件です。除外した3件も、扱いの記録に見える形で残します。対象条件を満たす投稿6件から、影響を受けた顧客6人を測定することはできません。これらの投稿から顧客離れを推定することもできません。