トラフィック フィルタリングのニーズに合わせて Magicgate を統合および構成するために必要なものすべて。
Magicgate を 5 分以内に起動して実行できます。このガイドでは、最初のトラフィック フローの作成、基本的なフィルターの構成、API を使用したテストについて説明します。
Magicgate は、構成可能なフィルターのセットに対してすべての訪問者を評価することで、ボット トラフィックを実際のユーザーから分離します。プラットフォームは、10 ミリ秒以内に「ホワイト」（ボット/crawler/unwanted）または「オファー」（実際のユーザー）のいずれかの評決を返します。
2 つの統合モードがあります。 API Mode を使用すると、REST エンドポイント経由で訪問者属性を送信し、アプリケーションが動作するための JSON 判定を受け取ることができます。 Direct Mode はすべてを自動的に処理します。ドメインを Magicgate に指定すると、コードを変更することなく、訪問者がフィルタリングされ、リダイレクトされます。
このクイック スタートは、開発中に最大限の制御と最速のフィードバック ループを提供するため、API Mode に焦点を当てています。慣れてきたら、ゼロコード統合が好まれる運用環境では Direct Mode に切り替えることができます。
magicgate.io でサインアップし、メール アドレスを確認してください。新しいワークスペースが表示されたダッシュボードが表示されます。
「フロー」に移動し、「フローの作成」をクリックします。わかりやすい名前を付けます (例: 「ランディング ページ - US Traffic」)。統合タイプとして API Mode を選択します。
少なくとも 1 つのフィルターを構成します。基本的な設定では、GeoIP (対象国) とボット検出 (既知のクローラーのブロック) を有効にします。後でさらにフィルターを追加できます。
オファー ページ URL (実際のユーザーがアクセスする場所) とホワイト ページ URL (ボットがリダイレクトされる場所) を設定します。
フローを保存します。設定ページからフローラベルとAPI keyをコピーします。
cURL または任意の HTTP クライアントを使用してテスト リクエストを送信します (以下の例を参照)。
ダッシュボードの [分析] タブをチェックして、テスト リクエストとその判定およびフィルターの内訳が表示されることを確認します。
curl -X POST https://api.magicgate.io/api/v1/check \
-H "Content-Type: application/json" \
-H "X-API-Key: your_api_key_here" \
-d '{
"label": "my-campaign",
"ip_address": "203.0.113.42",
"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
"referer": "https://google.com"
}'
# Response:
# {
# "verdict": "offer",
# "url": "https://example.com/landing",
# "display_mode": "redirect",
# "filter_reason": "",
# "processing_ms": 8
# }Magicgate が 29 以上の構成可能なフィルター、リアルタイムの IP インテリジェンス、および動作分析を使用してボット トラフィックを識別および分類する方法を理解します。
Magicgate は、多層の検出パイプラインに対してすべての受信訪問者を評価します。各フィルターは独立して実行され、最終的な判定に貢献します。評価全体は 10 ミリ秒未満で完了し、実際のユーザーが知覚できる遅延はゼロになります。
検出パイプラインは、ネットワーク レベルのチェック (IP レピュテーション、GeoIP、VPN/proxy/Tor 検出、データセンターの識別)、ブラウザ レベルのチェック (ユーザー エージェント分析、JavaScript フィンガープリント、ヘッダーの一貫性)、動作チェック (クリック パターン、セッション速度、リファラー検証)、およびリスト ベースのチェック (ブロックリスト、許可リスト、ISP フィルタリング) のいくつかのカテゴリに分かれています。
各フィルターはフローごとに個別に有効または無効にすることができます。このきめ細かな制御により、さまざまなトラフィック ソースの検出を微調整できます。たとえば、米国のモバイル ユーザーをターゲットにしたキャンペーンでは、ISP フィルタリングを無効にしながら、GeoIP (米国のみ)、VPN/プロキシ検出、およびモバイル デバイスの検証を有効にすることができます。
GeoIP フィルタリングは、ローカルでホストされている MaxMind データベースを使用し、遅延ゼロのルックアップのために毎週更新されます。国、地域、都市ごとにトラフィックをターゲットにしたり除外したりできます。このデータベースは、99.8% の国レベルの精度で IPv4 および IPv6 アドレスをカバーしています。
VPN、プロキシ、Tor 検出は、複数の商用データベースとオープンソース データベースを組み合わせます。 Magicgate は、既知の VPN 出口ノード、パブリックおよびプライベート プロキシ サーバー、Tor 出口リレー、および住宅用プロキシ ネットワークのリストを継続的に更新して維持します。検出は、IPv4 と IPv6 の両方の範囲をカバーします。
データセンター検出では、クラウド プロバイダー (AWS、GCP、Azure、DigitalOcean、OVH、Hetzner、その他 200 以上) から発信されたトラフィックを特定します。これは、仮想マシン上で実行されている自動スクリプトやヘッドレス ブラウザを捕捉する場合に特に効果的です。
ユーザー エージェント分析では、既知のクローラー、ボット、自動化ツールのデータベースと照合して訪問者のユーザー エージェント文字列を解析します。また、不一致も検出します。たとえば、ユーザー エージェントが Windows 上の Chrome であると主張しているにもかかわらず、Linux 固有のヘッダーを送信しているなどです。
ブロックリスト フィルターを使用すると、常にボットとして分類する必要がある IP アドレス、IP 範囲 (CIDR 表記)、およびユーザー エージェント パターンのカスタム リストを管理できます。逆に、ホワイトリスト フィルターを使用すると、常に通過する必要がある信頼できる IP (独自のテスト インフラストラクチャなど) をホワイトリストに登録できます。
Referer 検証では、予期されるパターンに対して HTTP Referer ヘッダーがチェックされます。特定のドメイン (例: Google、Facebook) からのトラフィックを要求したり、空のリファラー、欠落しているリファラー、または疑わしいリファラーを含むトラフィックをブロックしたりできます。
# Check a visitor with full attributes for bot detection
curl -X POST https://api.magicgate.io/api/v1/check \
-H "Content-Type: application/json" \
-H "X-API-Key: your_api_key_here" \
-d '{
"label": "my-campaign",
"ip_address": "203.0.113.42",
"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
"referer": "https://www.google.com/search?q=example"
}'
# Response with verdict and detection details:
# {
# "verdict": "offer",
# "url": "https://example.com/offer",
# "display_mode": "redirect",
# "filter_reason": "",
# "processing_ms": 8,
# "country_code": "US",
# "is_vpn": false,
# "is_bot": false,
# "is_datacenter": false
# }Magicgate がフィルターの判定に基づいて訪問者を正しい目的地にルーティングする方法を学びましょう。ホワイト ページとオファー ページのモデル、リダイレクト メカニズム、および判定処理を理解します。
Magicgate の核心はトラフィック ルーターです。すべての訪問者は構成されたフィルターに対して評価され、「オファー」 (正規ユーザー) または「ホワイト」 (ボット、クローラー、または不要なトラフィック) の判定が割り当てられます。判定により、訪問者がどこにリダイレクトされるかが決まります。
オファー ページは、実際のランディング ページ、オファー ページ、またはコンバージョン ファネル、つまり実際の人間の訪問者に見てもらいたいページです。ホワイト ページは、ボット、クローラー、広告ネットワークのレビュー担当者に表示されるおとりまたは無害なページです。一般的なホワイト ページには、単純なブログ投稿、ニュース記事、または一般的な情報コンテンツが含まれます。
この分離はキャンペーンを保護するために不可欠です。広告ネットワークのコンプライアンス審査担当者、クリック詐欺ボット、競合他社にはホワイト ページが表示されますが、ターゲット ユーザーの本物のユーザーはオファー ページにアクセスします。ルーティングは透過的にワイヤスピードで行われます。
Direct Mode では、ルーティングは完全に自動です。ドメインの DNS を Magicgate に指定すると、プラットフォームはリクエストのライフサイクル全体を処理します。つまり、訪問者の受信、フィルターの評価、適切な宛先への HTTP リダイレクト (デフォルトでは 302) の発行が行われます。訪問者が中間ページを見ることはありません。
API Mode では、アプリケーションは訪問者属性を使用して /api/v1/check エンドポイントを呼び出し、判定と推奨されるリダイレクト URL を含む JSON 応答を受け取ります。その後、アプリケーション自体がリダイレクトを処理します。これにより、ユーザー エクスペリエンスを完全に制御できるようになり、リダイレクトする前にカスタム ロジック、ログ記録、または A/B テストを追加できます。
Magicgate は、訪問者をルーティングするために 3 つの表示モードをサポートしています。 「リダイレクト」(デフォルト) は、宛先 URL への HTTP リダイレクトを発行します。 「プロキシ」は、ブラウザのアドレス バーを変更せずに、元の URL で宛先ページのコンテンツを提供します。 「iframe」は、元の URL の iframe 内に宛先ページを読み込みます。表示モードはフローごとに設定可能です。
判定は同期的に処理され、同じ訪問者からの迅速な連続リクエスト (最初のリダイレクト後のページ リソースの読み込みなど) を処理するために短時間キャッシュされます。キャッシュ TTL はフローごとに設定可能で、デフォルトは 30 秒です。
# API Mode: Get verdict and redirect URL
curl -X POST https://api.magicgate.io/api/v1/check \
-H "Content-Type: application/json" \
-H "X-API-Key: your_api_key_here" \
-d '{
"label": "my-campaign",
"ip_address": "203.0.113.42",
"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
}'
# Successful response:
# {
# "verdict": "offer",
# "url": "https://example.com/offer",
# "display_mode": "redirect",
# "filter_reason": "",
# "processing_ms": 8
# }Magicgate が提供する 2 つの統合モードを比較してください。最大限の制御のためにいつ API Mode を使用するのか、また、いつ Direct Mode が最も単純な展開パスを提供するのかを理解してください。
Magicgate は 2 つの異なる統合モードを提供し、それぞれが異なる使用例と技術要件に合わせて設計されています。適切なモードを選択すると、展開の複雑さ、ユーザー エクスペリエンスの制御、運用上のオーバーヘッドに影響します。
API Mode はプログラムによる統合です。アプリケーションは、訪問者の属性 (IP アドレス、ユーザーエージェント、リファラーなど) を含む POST リクエストを /api/v1/check エンドポイントに送信し、判定を含む JSON レスポンスを受け取ります。次に、コードがルーティングを処理し、ボットをホワイト ページにリダイレクトし、実際のユーザーの通過を許可します。このモードでは、統合コードを記述する必要がありますが、リクエスト フローを完全に制御できます。
Direct Mode は、DNS レベルの統合です。ドメインの DNS レコード (CNAME から proxy.magicgate.io、またはルート ドメインの場合は ALIAS/ANAME) が Magicgate を指すように構成します。訪問者が到着すると、Magicgate は透過的にリクエストを傍受し、訪問者を評価し、オファー ページまたはホワイト ページへの HTTP リダイレクトを発行します。アプリケーションでコードを変更する必要はありません。フィルタリング層とルーティング層全体がオリジン サーバーの前に配置されます。
API Mode の利点: ルーティング ロジックを完全に制御します。判定の受信とユーザーのリダイレクトの間に、ログ記録、A/B テスト割り当て、Cookie 設定、分析イベント、判定メタデータに基づく条件付きロジックなどのカスタム処理を追加できます。 API Mode はどのバックエンド スタックでも動作し、DNS の変更は必要ありません。また、クライアント側の JavaScript がチェック呼び出しを行うシングルページ アプリケーション (SPA) にも最適です。
API Mode 欠点: アプリケーションのコード変更が必要です。 API 呼び出し、エラーケース (タイムアウト、レート制限)、およびリダイレクト ロジックを処理する必要があります。 API 呼び出しにより、ページの読み込み時間にネットワークの往復時間が追加されます (Magicgate のエッジへの地理的な近さに応じて、通常は 10 ～ 50 ミリ秒)。
Direct Mode の利点: コードの変更はゼロです。 DNS をポイントしてフローを設定します。訪問者は自動的にフィルタリングされ、リダイレクトされます。 Direct Mode は追加の API ラウンドトリップがないため、エンドユーザーにとって高速です。フィルタリングは、DNS 解決と最初の HTTP リクエストの一部としてエッジで行われます。また、すべてのエッジケース (タイムアウト、再試行) も透過的に処理します。
Direct Mode 欠点: ルーティング プロセスの制御が低下します。判定とリダイレクトの間にカスタム ロジックを挿入することはできません。 DNS 変更はゆっくりと（数分から数時間）伝播するため、テストとロールバックが遅くなります。 Direct Mode では、ホワイト ページとオファー ページに公開 URL 経由でアクセスできることが必要です。
ハイブリッドアプローチも可能です。メインのランディング ページ (ゼロコード統合が優先される場合) には Direct Mode を使用し、カスタム判定処理が必要な特定のエンドポイント (フォーム送信、API エンドポイント、チェックアウト フローなど) には API Mode を使用します。
# ---- API Mode: Manual check + redirect ----
# Send visitor data and receive a verdict
curl -X POST https://api.magicgate.io/api/v1/check \
-H "Content-Type: application/json" \
-H "X-API-Key: your_api_key_here" \
-d '{
"label": "my-campaign",
"ip_address": "203.0.113.42",
"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
"referer": "https://google.com"
}'
# ---- Direct Mode: DNS configuration ----
# Point your domain to Magicgate's proxy:
# CNAME landing.example.com -> proxy.magicgate.io
# For root domains that don't support CNAME, use ALIAS/ANAME:
# ALIAS landing.example.com -> proxy.magicgate.io
# No API calls needed -- Magicgate handles everything at the edge.Magicgate アカウントにカスタム ドメインを追加し、DNS レコードを構成し、ドメイン検証を管理します。 Cloudflareの統合とSSL証明書の処理が含まれます。
すべての Magicgate アカウントは、すぐに使用できる共有ドメイン (go.magicgate.io) にアクセスできます。Starter プラン以降では、ブランド URL のカスタム ドメインを追加したり、広告ネットワークの信頼シグナルを強化したりできます。
カスタム ドメインを使用すると、共有ドメインの代わりに独自の URL (例: track.yourbrand.com) を使用できます。これは広告コンプライアンスにとって重要です。多くの広告ネットワークは、共有追跡ドメインではなくブランド ドメインからのトラフィックに対して寛容です。
Magicgate は、サブドメイン (track.yourbrand.com) とルート ドメイン (yourbrand.com) の両方をサポートしています。サブドメインは、メイン Web サイトの DNS 構成に干渉せず、管理が容易なため、お勧めします。
ドメインの検証では、proxy.magicgate.io を指す CNAME レコードが使用されます。ドメインを追加するときは、ドメインから proxy.magicgate.io に CNAME レコードを設定します。 CNAME レコードをサポートしていないルート ドメインの場合は、代わりに proxy.magicgate.io を指す ALIAS または ANAME レコードを使用してください。 Magicgate は、DNS レコードがプロキシ エンドポイントに正しく解決されることを確認することで所有権を検証します。
SSL 証明書は、DNS の伝達が完了した後、Let's Encrypt 経由で自動的にプロビジョニングされます。 Magicgate は証明書の発行、更新、インストールを処理します。カスタム ドメインは、DNS 構成から数分以内に、有効な証明書を使用して HTTPS 経由でトラフィックを処理します。
Cloudflare ユーザーの場合は、Magicgate を指す CNAME レコードに対してプロキシ (オレンジ色の雲) が無効になっていることを確認してください。 Cloudflareのプロキシは、Magicgateに到達する前にトラフィックを傍受するため、訪問者の評価が妨げられる可能性があります。レコードを「DNS のみ」(灰色の雲) モードに設定します。
Magicgate のマーケットプレイスを通じてドメインを直接購入することもできます。これらのドメインは事前構成されており、すぐに使用できるようになっており、DNS のセットアップや検証は必要ありません。マーケットプレイスは、トラフィック キャンペーンに適したクリーンなドメインのセレクションを提供します。
[設定] > [ドメイン] に移動し、[ドメインの追加] をクリックします。カスタム ドメイン (例: track.yourbrand.com) を入力します。
DNS プロバイダーに CNAME レコードを追加します: 名前 = ドメイン、値 = proxy.magicgate.io。ルート ドメインの場合、プロバイダーが apex ドメインで CNAME をサポートしていない場合は、ALIAS/ANAME を使用します。 DNS の伝達には最大 24 時間かかる場合があります。
Magicgate ダッシュボードで「DNS を検証」をクリックします。検証が完了すると、SSL 証明書が自動的にプロビジョニングされます。ドメインのステータスがアクティブに変わります。
# Verify DNS configuration using dig
# Check CNAME record points to Magicgate proxy
dig CNAME track.yourbrand.com +short
# Expected: proxy.magicgate.io.
# Check SSL certificate is provisioned
curl -vI https://track.yourbrand.com 2>&1 | grep "SSL certificate"
# Expected: SSL certificate verify okWebhook を設定して、交通イベントのリアルタイム通知を受信します。ペイロード構造、再試行ロジック、署名検証、イベント タイプについて学びます。
Webhooks を使用すると、Magicgate アカウントでフローの変更、ドメインの検証、支払いの更新などの重要なイベントが発生したときに、リアルタイムの HTTP POST 通知を受け取ることができます。
Magicgate は、複数のカテゴリにわたる Webhook イベントをサポートします: フロー イベント (flow.created、flow.updated、flow.deleted)、ドメイン イベント (domain.added、domain.verified、domain.deleted、domain.registration_failed)、ホワイト ページ イベント (white_page.ready、white_page.failed、 White_page.deleted)、ブラックリスト イベント (blacklist.created、blacklist.updated、blacklist.deleted)、API key イベント (apikey.created、apikey.deleted、apikey.activated、apikey.deactivated)、ウォレット イベント (wallet.credited、 wallet.debited)、サブスクリプション イベント (subscription.changed、subscription.canceled、subscription.plan_changed など)、請求イベント (payment.completed、payment.failed)、サポート イベント (ticket.created、ticket.replied、ticket.resolved、 ticket.closed)。
各 Webhook 配信には、X-Webhook-Signature (HMAC-SHA256 16 進ダイジェスト)、X-Webhook-Timestamp (Unix タイムスタンプ)、および X-Webhook-ID (エンドポイント識別子) の 3 つのセキュリティ ヘッダーが含まれています。この署名は、タイムスタンプと本文を一緒にカバーし、HMAC-SHA256(secret, timestamp + '.' + body) として計算され、改ざんとリプレイ攻撃の両方を防ぎます。署名を検証し、タイムスタンプが 5 分より古いリクエストを拒否する必要があります。署名シークレットは Webhook エンドポイントの作成時に生成され、一度表示されます。安全に保管してください。
Magicgate は失敗した Webhook 配信を再試行します。エンドポイントが 2xx 以外のステータス コードを返した場合、または 10 秒以内に応答しなかった場合、配信は再試行されます。すべての再試行が完了すると、イベントは失敗としてマークされ、エンドポイントの失敗数が増加します。
Webhook ペイロードは、{ id, event, timestamp, data } の構造で JSON エンコードされます。 「event」フィールドにはイベント タイプ文字列 (例: 「domain.verified」)、「id」は冪等性のための一意の配信 ID、「timestamp」は ISO 8601 日時、「data」にはイベント固有の詳細が含まれます。
アカウントごとに複数の Webhook エンドポイントを構成し、それぞれが異なるイベント タイプをサブスクライブできます。これにより、たとえば、ドメイン イベントを展開パイプラインにルーティングしたり、請求イベントを会計システムにルーティングしたりできます。
Magicgate ダッシュボードで [設定] > Webhooks に移動します。
[エンドポイントの追加] をクリックし、Webhook URL (HTTPS である必要があります) を入力します。
受信したいイベントの種類 (flow.created、domain.verified、payment.completed など) を選択します。
作成後に表示される署名シークレットをコピーします。それを環境変数に保存します。
POST リクエストを受信して署名を検証する Webhook ハンドラーをサーバーに実装します。
ダッシュボードの「テストイベントの送信」ボタンを使用して Webhook をテストします。
Webhook ログ タブで配信ステータスを監視し、正常に受信されたことを確認します。
# Test webhook endpoint manually
# Headers match what Magicgate sends: X-Webhook-Signature, X-Webhook-Timestamp, X-Webhook-ID
TIMESTAMP=$(date +%s)
BODY='{"id":"evt_1234567890","event":"domain.verified","timestamp":"2024-01-15T10:30:00Z","data":{"domain":"track.yourbrand.com"}}'
SECRET="your_webhook_secret"
SIGNATURE=$(echo -n "${TIMESTAMP}.${BODY}" | openssl dgst -sha256 -hmac "$SECRET" | awk '{print $2}')
curl -X POST https://your-server.com/webhooks/magicgate \
-H "Content-Type: application/json" \
-H "X-Webhook-Signature: $SIGNATURE" \
-H "X-Webhook-Timestamp: $TIMESTAMP" \
-H "X-Webhook-ID: endpoint-uuid-here" \
-d "$BODY"Magicgate ウォレットベースの請求モデル、サポートされている支払いプロバイダー、およびプラン管理を理解します。ダッシュボードからサブスクリプションと入金を管理します。
Magicgate はウォレットベースの課金モデルを使用します。暗号通貨デポジットを通じてウォレットに資金を追加すると、サブスクリプションは各請求サイクルでウォレットの残高から自動更新されます。これにより、カードへの定期的な請求が不要になり、支出を完全に制御できるようになります。
CCPayment、NowPayments、TransVoucher の 3 つの支払いプロバイダーがサポートされています。各プロバイダーは、ビットコイン、イーサリアム、USDT、USDC、および 50 以上の追加の暗号通貨をサポートしています。入金を開始すると、支払いアドレスと金額が生成されます。ブロックチェーンがトランザクションを確認すると、ウォレットの残高が自動的に更新されます。
プランにより、月ごとのチェック、フロー数、フローごとのルール、API アクセス、カスタム ドメインなどの機能制限が決まります。認証なしで利用可能なプランを表示できます。アップグレードまたはダウングレードはすぐに有効になります。現在の期間の未使用残高は日割り計算され、ウォレットに返金されます。
サブスクリプションは月単位または年単位で行うことができます。年間サブスクリプションには割引があります。いつでもキャンセルできます。サブスクリプションは現在の請求期間が終了するまでアクティブのままです。キャンセルされたサブスクリプションを再開すると、新しいサブスクリプションを作成せずに復元されます。
ウォレットは、入金、サブスクリプション料金、返金、日割りクレジットなど、すべてのトランザクションを追跡します。各トランザクションには、元のイベント (入金、サブスクリプションの更新、プランの変更など) にリンクする参照タイプと ID が含まれます。
パブリック /billing/plans エンドポイントを使用して利用可能なプランを確認し、ニーズに合った適切なプランを見つけてください。
サインアップして、ダッシュボードで [設定] > [請求] に移動します。
ウォレットに資金を追加します。「入金」をクリックし、支払いプロバイダーと暗号通貨を選択し、金額を入力します。
生成されたアドレスを使用して暗号通貨の支払いを完了します。ブロックチェーンの確認後にウォレットが更新されます。
プランを購読します。サブスクリプション料金はウォレットの残高から差し引かれます。
「請求」セクションでウォレットの残高と取引履歴を監視します。
残高不足アラートを設定して、ウォレットに次回の更新に十分な資金があることを確認します。
# List available plans (public -- no auth required)
curl -s https://api.magicgate.io/api/v1/billing/plans | jq '.data'
# Check enabled payment providers (public)
curl -s https://api.magicgate.io/api/v1/billing/providers | jq '.data'
# { "ccpayment": true, "nowpayments": true, "transvoucher": false }Magicgate ダッシュボードを効果的に操作します。分析ビュー、フロー管理、設定パネル、およびトラフィック フィルタリングをリアルタイムで監視する方法を理解します。
Magicgate ダッシュボードは、トラフィック フローの管理、分析の監視、アカウント設定の構成を行うための中央コントロール パネルです。ログインすると、アカウントの主要な指標の概要を示す [概要] ページが表示されます。
[概要] ページには、処理された小切手の合計数、判定分布 (オファーと白)、アクティブなフロー、および最近のアクティビティが表示されます。時系列グラフには、過去 24 時間、7 日間、または 30 日間のトラフィック量が表示されます。これにより、トラフィックの健全性とフィルタリングの有効性を即座に把握できます。
「フロー」セクションでは、トラフィック フローを作成および管理します。各フローは、フィルターのセット、オファー ページ URL、ホワイト ページ URL、統合設定 (API Mode または Direct Mode) など、個別のフィルター設定を表します。さまざまなキャンペーン、ランディング ページ、またはトラフィック ソースに対して複数のフローを設定できます。
各フローの詳細ビュー内で、フローごとの分析 (合計チェック、判定の内訳、フィルター ヒット率、地理的分布、上位参照元) を確認できます。この詳細なデータは、特定のキャンペーンごとにフィルター設定を最適化するのに役立ちます。
[分析] セクションでは、すべてのフローにわたる包括的なビューが提供されます。グラフには、長期にわたる判定傾向、フィルターの有効性 (どのフィルターが最も頻繁にトリガーされるか)、トラフィックの発信元を示す地理的なヒートマップ、デバイスとブラウザーの内訳、および時間ごとのトラフィック パターンが含まれます。すべてのグラフは、日付範囲フィルタリングとフロー固有のフィルタリングをサポートしています。
「ドメイン」セクションには、構成されているすべてのドメイン (共有およびカスタム) がリストされます。各ドメインについて、そのステータス (アクティブ、検証保留、DNS エラー)、SSL 証明書のステータス、および関連するフローを確認できます。ドメインの健全性チェックが自動的に実行され、DNS または SSL の問題が検出された場合は警告が表示されます。
「設定」セクションには、アカウント全体の構成が含まれています。 API キー: 有効期限をオプションで指定して API key を生成および管理します。 Webhooks: Webhook エンドポイントを構成し、配信ログを表示します。プロバイダー: 支払いプロバイダーと DNS プロバイダーを追加および管理します。請求: ウォレットの残高、チャージ履歴、サブスクリプションのステータスを表示します。チーム: 役割ベースのアクセス権 (ユーザー、管理者) を持つチーム メンバーを招待します。
ダッシュボードは、右上隅にあるテーマの切り替えにより、明るいテーマと暗いテーマの両方をサポートします。すべてのページは応答性が高く、モバイル デバイスでも動作しますが、デスクトップ エクスペリエンスでは最も包括的なデータ ビューが提供されます。