Google Search APIを使用して会社のウェブサイトを見つける

TL;DR:

• 企業ウェブサイトの発見は、確認されたマッチの前に候補を生み出します。 企業名を含む結果は、ウェブサイトの所有権を確立するものではありません。
• エンティティコンテキストで検索します。 レビューアが類似した組織を区別できるよう、企業識別子、名称、市場、ビジネスの説明を保持してください。
• マッチの背後にある証拠を記録します。 候補のURL、エンティティチェック、不確実性、および企業とウェブサイトのテーブルの最終レビューアの決定を保持します。

企業リストには、信頼できるウェブサイトのURLを伴わない名前が含まれていることがよくあります。一部の名前は無関係なビジネスによって共有されており、他は子会社、以前のブランド、または場所を指すことがあります。最初の検索結果を選択すると、その曖昧さが、データセットの残りの部分に広がる自信を持ったエラーに変わる可能性があります。

Scrapeless Google Search API は、企業ウェブサイトの発見のための構造化された検索結果を提供します。ここでのワークフローは、それらの結果を使用して候補キューとレビューされたマッピングを構築します。それは、完全な企業データベース、連絡先情報、または確認されたメールアドレスを提供することを主張していません。

どの企業とどのウェブサイトが必要かを定義する

入力データセットから安定した企業識別子で始めます。名前は検索に便利ですが、マッピングの主キーにすべきではありません。2つのレコードは名前を共有することができ、異なるエンティティを表すことがあります。

組織名は受け取ったそのままにし、別のフィールドに既知のコンテキストを追加します：運営市場、業界、場所、親組織、または製品名。それらのコンテキストの出処を保持します。未確認のエンリッチメントは、次のフィールドを検証するために使用される証拠に静かに変わってはいけません。

希望するURLが何を表すかを決定します。企業のホームページ、地域のサイト、ブランドサイト、子会社のサイトは異なる目的地です。有効な子会社ページは、親会社のルートドメインが期待されているという明示されていないルールに基づいて拒否されるべきではありません。

研究を始める前に受け入れられる結果を定義します：確認されたマッチ、レビューが必要な妥当な候補、未解決の曖昧性、収集されたサンプルにおける確認されたマッチなし。確認されたマッチがない記録は、理由が明示されていれば有用です。

知られているコンテキストからクエリを構築する

企業名と少しの関連コンテキストを使用します。業界や地理は、共有名を区別するのに役立ちます。各クエリと企業識別子を一緒に保持し、レビューアが検索の意図されたエンティティを知ることができるようにします。

クエリをより具体的に見せるために想像上の事実を追加しないでください。推測された都市は、誤った組織に検索を向け、その後推測を確認するように見えることがあります。入力レコードがコンテキストを欠いている場合は、曖昧さをマークし、独自のワークフロー内でより良いソースデータを要求してください。

Google Searchパラメータ は、国、言語、そして場所のコントロールを提供します。これらを意図的に設定し、完全なリクエストを保持します。国のコンテキストは企業の登録や所有権の証明ではなく、あなたが観察するように依頼した検索を説明します。

具体的な不確実性を解決する場合は、別の独立して正当化されたクエリを使用します。たとえば、会社が以前の名前を使用しているかどうかなどです。観察結果は別々に保持します。クエリの変動は研究活動であり、元の入力レコードを書き直す理由ではありません。

候補と元の証拠を収集する

Google Searchリクエストワークフロー は、scraper.google.search を使用して POST https://api.scrapeless.com/api/v1/scraper/request と x-api-token ヘッダーで機能します。設定は input の内部に存在します。ライブコレクションにはあなたのアカウントキーと実際の応答の検査が必要です。このワークフローは、認証された実行を主張しません。

完全なリクエスト、未処理の応答、クライアントの観察時間、そして企業識別子を保存します。HTTP 200 はタスクデータを運び、HTTP 201 は保留中のタスクを意味します。コレクションが保留中または失敗したために、企業をウェブサイトを持たないとラベル付けしないでください。

オーガニック結果については、返されたタイトル、URL、スニペット、そして位置を保持します。欠落またはnullフィールドは、発明されたテキストと置き換えるのではなく、生の記録にそのまま保持します。JSONデータモデルは、その区別をサポートします。

所有権を割り当てる前に候補行を作成します。ディレクトリリスト、ニュース記事、または同様に名付けられた会社は、望ましいホームページでなくても有用な証拠となる場合があります。候補の明らかな役割を、マッチであるかどうかとは別にマークします。

所有権を主張せずにホスト名をグループ化する

URLパーサーを使用して、スキーム、ホスト名、パス、クエリを分離します。 URL解析リファレンス は、これらのコンポーネントを説明し、解析がサイトのアイデンティティの検証ではないことを明確にしています。

部分文字列の所有権ルールを回避します。ブランドワードを含むホスト名は、無関係な当事者に属する可能性があります。明示的にレビューされたホスト名を比較し、元のURLを保持します。組織が選択されたサブドメインをグループ化する場合、そのポリシーを記録し、すべての共有サフィックスが同じビジネスを識別すると仮定しないでください。

ルートドメインの計算にも注意が必要です。公開サフィックスは異なるため、ホスト名の最終ラベルを取得することは一般的な所有権テストではありません。 公開サフィックスリストの説明 は、ドメイン境界を明確にするのに役立ちますが、ドメイン背後のビジネスを検証するものではありません。

ディレクトリやソーシャルプロファイルは証拠キューに保持しますが、会社のウェブサイトと区別します。レビューの後に組織を明確化するのに役立ちますが、自動的に最終ホームページになることはありません。

Scrapelessでスクレイピングを開始する

Scrapelessでウェブスクレイピングと自動化ワークフローを強化しましょう！
今日サインアップして**$5の無料クレジット**を獲得 — クレジットカード不要。

Scrapeless Dashboard で今すぐ無料クレジットを請求してください。

目的のページでエンティティを確認する

各有望な目的を開き、ビジネスのアイデンティティを確認します。組織の説明、所在地、製品、親関係を既知の入力コンテキストと比較します。ナビゲーションがリダイレクトされる場合は、要求されたURLと最終目的を保持します。

会社名だけで決定を下さないでください。共有名と不適合な業界の組み合わせは対立です。たとえ結果が目立っても、名前の一致と一貫したビジネスコンテキストはより強力な証拠ですが、確認した内容を記録し、説明のない信頼スコアの後ろに隠さないでください。

検索スニペットは発見の証拠として残ります。Googleは、スニペットが生成される方法を説明しています。これらは、クエリに関連するテキストを強調できます。ターゲット企業を識別する前に、目的地をレビューしてください。

ハーバーアナリティクスと呼ばれる仮想入力の場合、レビュー担当者はソフトウェアビジネスと無関係なコンサルティング会社を見つけるかもしれません。その例は、観察された検索結果ではなく、意思決定プロセスを示しています。不十分な入力コンテキストに対する正しい反応は、推測されたホームページではなく未解決の一致です。

検討可能な会社とウェブサイトの表を作成する

最終表は決定を検査可能にするべきです。会社ID、入力名、選択されたURL、選択されたホスト名、ウェブサイトの役割、一致状態、証拠参照、レビュアー、およびレビュー時間を保持します。別の候補テーブルは、すべての調査済みURLと除外理由を保持できます。

明示的な状態とともにのみ空の選択されたURLを使用します。「確認された一致なし」は収集された候補が不十分であったことを意味することがありますが、「曖昧」は利用可能なコンテキストに適合する複数の目的地があることを意味することがあります。いずれの声明も、組織がウェブサイトを持っていないことを証明するものではありません。

リダイレクトと履歴名は、内部システムの日付付き観察として保持します。後の検索で異なるランディングページが返された場合に、自動的に確認されたマッピングを上書きしないでください。代わりに、古い証拠と新しい証拠を使ってレビューイベントを作成します。

データセットがCRMにフィードされる場合、会社レベルのマッピングを正しい組織レコードに添付します。タスクは会社のウェブサイトに限ります。個人の連絡先収集とメール検証は別のワークフローであり、このプロセスの成果物ではありません。

コレクションを拡張する前にレビューの質を測定する

受け入れられた一致と拒否された一致のサンプルを同じ文書化された基準に対してレビューします。レビュアー間の意見の不一致と曖昧さの源を記録します。これにより、問題がクエリのコンテキスト、ウェブサイトの役割ルール、または不十分なソースデータにあるのかを明らかにします。

コレクションのカバレッジを一致の結果から分離します。レポートは、完了した計画された検索とレビューされた一致を受けた企業を示すことができます。提出されたすべての検索が実用的な証拠を生成したかのように扱わないでください。

便利な未解決のキューは、次に必要な情報を記録します：法的名称、市場、親関係、またはレビューされた目的地。それはデータ所有者にとって実用的な引き継ぎです。一般的な低信頼ラベルは、次の人に明確な行動を残さないことがよくあります。

結論

会社のウェブサイト発見を、エビデンスに基づいたマッチングプロセスとして構築します。検索は候補の目的地を見つけ、ホスト名処理はそれらを整理します。ページレビューは、それらが意図したエンティティとウェブサイトの役割に適合するかどうかを確立します。不確実性を保持し、クリーンなテーブルが不正確なマッチを隠さないようにします。

レビューされた会社のウェブサイトは、コンテンツの背後にある組織を区別することによって、コンテンツギャップ分析のスコープを助けることもできます。

次の検索観察を構築する

Scrapeless Google Search APIを使用して、このワークフローのための検索証拠を収集します。収集予算を計画する際には、Scrapelessの料金を確認し、リクエスト設定の傍にGoogle検索パラメータを置いておきます。

DiscordやTelegramでコミュニティと実装について議論してください。

FAQ

Q: 最初のオーガニック結果は公式の会社ウェブサイトですか？

必ずしもそうではありません。それは候補です。目的地のビジネスアイデンティティを知られた会社のコンテキストと比較してから受け入れてください。

Q: ドメインを見つけることはメールアドレスを検証しますか？

いいえ。このワークフローは、企業をレビューされたウェブサイトにマッピングします。メールアドレスを収集または検証することはありません。

Q: ディレクトリのリストは廃棄するべきですか？

レビュー後に支持証拠として残ることはできますが、会社の自社ホームページではなくディレクトリとしてラベル付けされるべきです。

Q: いくつかの会社が同じ名前を持っている場合はどうしますか？

業界、市場、親組織などの信頼できるコンテキストを使用してください。利用可能な証拠がそれらを区別できない場合、マッチを未解決のままにしてください。

Q: 確認されたマッチがないということは、会社にはウェブサイトがないということですか？

いいえ。これはこの調査サンプルの結果を示しています。不完全な収集、不十分なコンテキスト、または未解決の候補がすべて確認されたマッチを防ぐ可能性があります。