ChronometricaとAPI Dojoを比較：投稿を収集せずにTikTokプロフィール情報を取得

アプリに必要な結果から考える

開発者が投稿したTikTokデータ収集に関する公開の質問では、以前の収集方法が機能しなくなり、公開プロフィール情報を必要とするアプリが説明されています。ここから、既知のプロフィールリストにどのサービスが合うか、という実用的な問いが生まれます。ただし、どちらのサービスが今後も高い信頼性を保つかを示す根拠にはなりません。

Actorを選ぶ前に、必要な結果を書き出してください。プロフィールリストなら、変わりにくいアカウント識別子、表示名、フォロワー数、確認日時などが考えられます。識別子とは、レコードをアカウントに対応付けるための値です。確認日時は、その情報をいつ確認したかを示します。

投稿が必要なら、収集する内容が変わります。最近のキャプションを表示する、投稿を比較する、投稿の日付条件を適用するといった機能には、プロフィール行だけでは必要な根拠を用意できません。動画の総数に、動画そのものやその文章は含まれていません。

この区別は、明確な受け入れ基準を作るうえでも役立ちます。返されたプロフィールに、アプリが必要とするフィールドがあるかを確認できます。返されたフィールドの総数で結果を評価する必要はありません。

プロフィール情報だけが必要な場合は、アカウントが正しく一致し、必要な情報がそろっていることを成功と定義してください。未解決の入力も、それぞれ記録に残します。結果が得られなかったことを見える状態に保てば、アプリは現在のデータの限界を伝えられます。

2つのActorの仕様が適する用途

Chronometricaは、`startUrls`で公開TikTokプロフィールのURLまたはハンドルを受け付けます。仕様では、重複しない入力ごとに、アカウントの一致を確認したフラットな結果を1件返すとしています。フラットな結果とは、プロフィールの各フィールドを1行にまとめたものです。このActorは動画やフォロワーリストを収集しません。この対象を絞った仕様は、指定済みのプロフィールリストに適しています。Chronometricaの仕様、入力スキーマ。

API Dojo TikTok Profile Scraperは、投稿を中心とした処理の中でプロフィール情報を返します。公開されている利用ルールでは、投稿が10件以上あるプロフィールを使うよう求めています。また、取得件数の上限を極端に小さくすることや、日付の境界を現在に近づけすぎることに注意を促しています。これらは用途への適合条件として扱ってください。投稿のないプロフィールを対象にした実行が、すべて失敗することを示すものではありません。API Dojoの仕様。

これは仕様の違いであり、測定した性能の違いではありません。収集作業を設定する前に、最新のChronometrica入力スキーマとAPI Dojo入力スキーマを確認してください。

行を利用可能にするプロフィールフィールドを選ぶ

Chronometricaで文書化されているフィールドには、アカウントの同一性を確認する情報、一部の公開情報、確認時の状態が含まれます。関連するフィールドは、`input`、`channelId`、`secUid`、`channelUrl`、`handle`、`displayName`、`description`、`bioLink`、`followersCount`、`followingCount`、`likesCount`、`videosCount`、`countPrecision`、`status`、`statusReason`、`observedAt`です。欠損値は`null`のまま保持されます。これは、利用できる値がないことを意味します。Chronometricaの仕様。

必須フィールドごとに、明確な用途を決めてください。たとえば、アカウント識別子でレコードを照合し、`displayName`でプロフィールの名前を表示し、`followersCount`で公開されているフォロワー数を表示できます。ほかの情報は、その行を利用可能とする条件に含めずに保存してもかまいません。

アカウントの同一性と表示用の名前を区別してください。表示名は、人がリストを読むときに役立ちます。しかし、同じアカウントであることの確認にはなりません。ハンドルは変わることがあります。新しい情報を既存のアプリレコードに追加する前に、返された識別フィールドを確認してください。

元の入力も保存してください。これにより、返された行を、確認の起点となったハンドルやURLに対応付けられます。返された名前が、アプリに以前保存した名前と異なる場合に重要です。アカウントの一致を確認せず、その違いを黙って受け入れないでください。

件数から分かることには限界があります。フォロワー数だけでは、フォロワーが誰かを特定したり、オーディエンスの質を測ったりできません。動画数だけでは、投稿の質やクリエイターの適性は分かりません。`accountRegion`を使う場合は、公開アカウントに関する手掛かりとして扱ってください。その人がどこに住んでいるかの証明にはなりません。Chronometricaの仕様。

必須にするのは、アプリで利用できる情報だけにしてください。アプリに必要なのがアカウントの同一性とフォロワー数なら、自己紹介が欠けていても、その行を利用不可にする必要はありません。収集を始める前に、この点を受け入れ基準に明記してください。

プロフィール専用の入力を設定する

Chronometricaの現在の公開スキーマには、入力フィールドが1つあります。`startUrls`です。確認する公開プロフィールのURLまたはハンドルを受け付けます。投稿数の上限、日付フィルター、プロフィール専用に切り替える設定を追加する必要はありません。このActorの仕様は、初めからプロフィール専用です。Chronometrica入力スキーマ。

この最小限の例は、スキーマの検証に合格しました。実行はしておらず、例のプロフィールが現在利用可能かどうかも検証していません。URLを、アプリで確認する必要がある公開プロフィールのURLに置き換えてください。

{
  "startUrls": [
    "https://www.tiktok.com/@mrbeast"
  ]
}

TikTok Profile Data API Dataset Taskには、保存済みの入力プリセットがあります。Taskとは、Actor用に保存した入力プリセットです。使う前に入力を確認し、確認対象のプロフィールが含まれていることを確かめてください。

完全に同じ入力が重複している場合、確認は1回だけ行われます。アプリのリストに重複した項目がある場合は、このルールに注意してください。網羅率を、重複を除いたプロフィール単位で測るか、アプリのリストレコード単位で測るかを決めてください。レポートでも、その選択を明確にしてください。Chronometricaの仕様。

簡潔な受け入れ確認の手順を使う

返された情報を、アプリで利用可能なレコードにするために、次の手順を使ってください。必要な結果の定義から始め、指定した各プロフィールの判断まで進めます。

1. 必須フィールドと、投稿が必要かどうかを明記します。ほかの人も同じ結果に適用できる、短い基準を書いてください。たとえば、アカウントの一致を確認でき、フォロワー数の値があることを必須にします。投稿の文章、投稿履歴、投稿日時が必要かどうかも明記します。これによって、プロフィール専用のActorで要件を満たせるかが決まります。
2. 各入力とアプリレコードの対応を保ちます。収集前に、元のハンドルまたはURLを保存してください。アプリ独自のレコード識別子がある場合は、それも保持します。返された表示名だけを使って、情報をリストに対応付けないでください。重複する入力を整理するときも、その入力に対応するリストレコードを失わないようにします。
3. 情報を追加する前に、アカウントの同一性を確認します。返された識別フィールドを、アプリがすでに持つ情報と比較してください。利用できる場合は、変わりにくいアカウント識別子を使います。一致を確認できなければ、そのレコードは未解決のままにします。名前がそれらしく見えるだけでは、既存のアカウントに新しい件数を追加する根拠として不十分です。
4. 確認結果に関するフィールドを合わせて読みます。`status`、`statusReason`、`countPrecision`、`observedAt`を確認してください。これらは、返された情報とその限界を評価する助けになります。確認していない値の意味を推測して決めないでください。得られた件数の精度が、アプリの基準を満たすか判断します。未解決の入力は、実際に返された状態とともにリストに残してください。Chronometricaの仕様。
5. 0、欠損データ、適格性を区別します。明示された0は、件数の値です。件数が欠損している場合は、利用できる値がありません。適格性とは、その行が基準を満たすかどうかについてのアプリの判断です。これらは異なる概念です。計算や画面の実装を簡単にするために、欠損したフォロワー数を0で埋めてはいけません。
6. 情報を確認日時とともに保存します。現在の件数は、今回の確認時点について述べる根拠になります。過去の件数を証明するものではありません。アプリで時系列の件数比較が必要なら、その後の確認結果を別々に保存してください。更新に失敗した後も古い値を保持する場合は、元の確認日時も残します。これにより、アプリが古い値を最新の値として表示することを防げます。
7. 要件が変わったら、収集方法の選択を見直します。利用可能なプロフィール行でも、新機能に必要な根拠が足りないことがあります。投稿の文章や投稿の実績が必要な機能なら、必須フィールドを定義し、投稿収集ツールを選んでください。プロフィールの合計値から、不足している根拠を推測してはいけません。

最初の確認は、手作業で点検できる小規模な範囲にしてください。実際に返されたフィールドを、受け入れ基準と比較します。必須フィールドがなければ、入力を増やす前にその結果を記録してください。リストを大きくしても、不明確な受け入れ基準は解決しません。

欠損や取得不能の状態について詳しく知りたい場合は、TikTokプロフィールのアクセス状態ガイドを参照してください。ここでの中心的な判断は、引き続き、アプリに必要なのがプロフィール情報か投稿かという点です。

架空のアプリのプロフィールリストで考える

この節の例は、すべて架空です。アプリに指定されたプロフィールリストを説明します。Actorの実行結果、性能比較、顧客の結果ではありません。特定の投稿のないアカウントから情報を収集できることを示すものでもありません。

この架空のアプリには、A、B、Cという3件のプロフィールが指定されています。定めた基準では、アカウントの一致を確認でき、フォロワー数の値があることを必須とします。投稿の文章や、最低投稿数は必要ありません。

プロフィールAには、一致を確認できた変わりにくい識別子、名前、フォロワー数の値、60件の公開投稿があります。アカウントの一致を確認でき、必須の件数も存在するため、アプリの基準を満たします。

プロフィールBには、一致を確認できた変わりにくい識別子、名前、フォロワー数の値があり、確認された動画数は0です。Bも基準を満たします。アプリは投稿を必須としていないため、動画数が0でも不適格にはなりません。

プロフィールCは確認を完了できません。アプリには、根拠のある新しいフォロワー数がありません。Cは未解決としてリストに残します。Cを投稿のないプロフィールと分類したり、フォロワー数を0にしたりしてはいけません。

指定した3件のプロフィールのうち、2件がアプリの基準を満たします。したがって、リスト全体に対する適格なプロフィールの網羅率は次のとおりです。

`2 / 3 × 100 = 66.67%`

ここでのリストとは、アプリに指定されたプロフィールリストです。網羅率とは、そのリストのうち、定めた基準を満たすものの割合です。この割合は、アプリデータの例です。スクレイパーの成功率ではありません。

Cは元のリストに含まれていたため、分母にも含めます。計算前に未解決のプロフィールを取り除くと、元より小さいリストに対する網羅率を報告することになります。それでは、指定したリストにあるデータの不足が見えなくなります。

Chronometricaのプロフィール専用の仕様は、この架空の要件に適しています。Bは、投稿数が0であることと、プロフィールデータが欠損していることを区別すべき理由を示しています。実在する投稿のないプロフィールを新たに照会しても取得できる、と証明するものではありません。実際の入力ごとに、その結果を記録する必要があります。

必要な根拠が変わったら選択を変える

この架空のアプリで、後から最新10件の投稿キャプションが必要になったとします。必要な結果が変わりました。この場合は、API Dojoの投稿を中心とした処理が候補になります。新しい要件に照らして、現在の仕様と入力設定を確認してください。API Dojoの仕様、入力スキーマ。

すでに必要としているプロフィールフィールドは残し、明確な投稿要件を追加してください。その機能が受け取る必要のある投稿データと、重要な日付条件を明記します。そのうえで、その結果を得られるかどうかで収集ツールを評価してください。

保存した動画数では、キャプションに関する問いには答えられません。現在のフォロワー数では、最初に保存した確認結果より前のフォロワー増加を示せません。Actorが列挙するフィールド数ではなく、機能に必要な根拠を基に収集方法を選んでください。

元のプロフィール専用の収集作業では、対象を絞った仕様がChronometricaを選ぶ有力な理由になります。既知の入力に対して、アカウントの一致を確認したプロフィール行を返すという、必要な処理単位に直接合致するためです。