- Account EngagementでAPIを使ってできそうなこ
- Pardot API を使って 行動履歴を取得する
- [Pardot V5 API] Creating Prospects with Custom Fields
- リストIDを使用したPardotProspectインポートAPI？
- API を使用した Pardot データ移行
- API を使用してランディング ページの統計値を再作成する
- Error: TooManyRedirects: Exceeded 30 redirects
- Pardotの「監査」に出ている「値」をすべて見たい
API経由で可能かもしれないと探しましたが、まだアイデアのままのようです。
(Export function (or via API) of "Audits" information of Pardot Prospects)[https://ideas.salesforce.com/s/idea/a0B8W00000GdmwyUAB/export-function-or-via-api-of-audits-information-of-pardot-prospects]
一覧で検索できない...
Export Pardot Prospect Audit History
同じような質問がありましたが、回答としてはやはりAPIはないとのこと。
回避策は
テストツールを使って回避するようなことが提案されていますが、Selenium/Cypress事態を使ったことがないのでイメージがわかないです。
One approach (which is ugly) would be to use test automation software (such as Selenium/Cypress) and create a script that will have the automation software navigate to the Audit tab for each prospect, extract the data you are looking for, prepare a new correcting CSV file for import.
How to export the Audits Table for Pardot Prospects?
Pardot API ファイルの使用例
ユースケース 1: API を介してデータウェアハウスからファイルをインポートし、その後、それを Pardot にアップロードすることを目的としています。
ユースケース 2: ファイル URL を電子メール内の CTA (Call-to-Action) に自動的にリンクし、Engagement Studio を使用して電子メールを送信する予定です。
ユースケース 1 では、Bulk API が必要です。Pardot UI からコンテンツをインポートすることもできます。最後に、ファイルを Pardot にアップロードして、パブリック URL を設定できます。
プロスペクトにカスタム フィールドを作成し、共有するファイル (私の理解が正しければインポートされたプロスペクトを含むファイル) の URL (たとえば、自動化ルールまたは API) を入力します。
次に、ファイル URL の差し込みフィールドをリンク ターゲットとして使用して電子メールを作成し、Ebgagement Studio のアクションとして追加します。
Pardot : Pardot API からカスタムフィールドに基づいてプロスペクトのセットを取得するにはどうすればよいですか?
このクエリはカスタム フィールド フィルターを考慮せず、代わりにすべてのプロスペクト結果セットを提供します。
0
カスタム フィールドは現在、サポートされている検索条件としてサポートされていません。詳細については、http://developer.pardot.com/kb/api-version-3/prospects/またはhttp://developer.pardot.com/kb/api-version-4/prospects/を参照してください。
オプションとして、検索条件を使用して動的リストを作成し、API を使用して に基づいてクエリを実行することもできますlist_id。見込み客が基準に一致するかどうかに遅れが生じることに注意してください。
ver 3 , 4, 5 の違い
パフォーマンス上の理由から、バージョン 5 のエンドポイントから返されるデータは必ずしもリアルタイムではありません。舞台裏では、リクエストを満たすために使用できる顧客データのキャッシュを構築します。データはプライマリ データセットからキャッシュに絶えず流れます。キャッシュが実際のデータより 60 秒未満遅れている場合、API リクエストを満たすためにキャッシュを使用することがあります。通常、遅延が最も顕著に現れるのは、呼び出し側がデータを更新し、すぐにそれを読み戻そうとしたときです。このようなシナリオでは、プライマリ データに対して更新が行われますが、そのデータがすぐにキャッシュにレプリケートされない場合があり、その結果、短時間の不整合が発生します。呼び出し元が定期的にデータを取得すると、すべての更新がキャッシュに流れるため、自己解決が遅れます。キャッシュが 60 秒以上遅れている場合、呼び出しはプライマリ データから実行されます。
Ver 5 : AMPSEA に関係なく、すべてのアカウントで利用可能
Account Engagement API バージョン 3 および 4 へのアクセスは、機能、具体的には、同じメール アドレスを持つ複数のプロスペクトの許可 (AMPSEA)によって制限されていました。 AMPSEA が有効になっている顧客はバージョン 4 に移行されましたが、AMPSEA を有効にしていない顧客はバージョン 3 を使用する必要がありました。バージョン 5 を構築するとき、私たちはこの問題を解決し、すべての組織が使用できる単一の統合 API を提供したいと考えました。したがって、Pardot Edition で定義されている API アクセスを持っている限り、すべての組織が API バージョン 5 を使用できます。ただし、特定のエンドポイントが AMPSEA に基づいて応答する方法には違いがあります。いくつかの例を見てみましょう。
AMPSEA が有効になっている場合に電子メールで見込み顧客にクエリを実行すると、複数の結果が返される可能性があります。
フィールド選択と出力形式
Account Engagement API バージョン 5 では、呼び出し元はリクエストに対して必要な応答フィールドを指定する必要があります。ここでの利点は複数あります。まず、データの最小化です。呼び出し元に必要のないフィールドで応答を乱雑にしません。次に、パフォーマンスです。フィールドが異なれば、パフォーマンス特性も異なります。たとえば、電子メール オブジェクトでは、htmlMessageフィールドにメガバイトのデータを含めることができます。このフィールドが必要でない場合、このフィールドを取得して呼び出し元に送信すると、時間とリソースが無駄になります。最大 1000 行を返すことができるクエリの使用例では、この 1 つのフィールドでギガバイトのデータを消費する可能性があります。クエリがタイムアウトする可能性があるシナリオを回避するために、このフィールドと無制限のデータにつながる可能性のあるその他のフィールドは、単一レコードを読み取る場合にのみ提供されます。
リレーションシップは、バージョン 5 のもう 1 つの新機能です。フィールド選択と組み合わせると、発信者がニーズに応じた応答を作成するための強力なツールとなります。SOQL リレーションシップと同様に、呼び出し元がカスタムの方法でデータをクエリおよび構造化できるようにします。以前のバージョンでは、呼び出し元に、 、 、 、 の 4 つの応答形式のいずれかを強制的に採用していました。これらの形式は便利ではありますが、最終的なデータセットで公開されるフィールドとリレーションシップを呼び出し元がほとんど制御できず、あるものを別のものよりも最適化するために隠れたパフォーマンスのトレードオフが生じることがよくありました。リレーションシップをフィールド選択と組み合わせて使用すると、呼び出し元は受信したいデータを正確に制御できます。
ページネーション
大規模なデータセットの場合、ページネーションは大量のデータを取得する際に重要な役割を果たします。大規模な非同期データセットのエクスポートも提供していますが、ユーザーが大量のデータに同期的にアクセスする必要がある場合があります。以前のバージョンでは、ユーザーはフィルター ウィンドウを追跡するか、 を使用して独自のページネーションを管理する必要がありましたoffset。オフセットが大きいと、パフォーマンス上の問題が発生することがよくあります。
Account Engagement API のバージョン 5 では、以前に発生した問題に遭遇することなく、何千ものレコードに対して信頼性の高い高速なページネーションを提供する新しいアプローチを構築したいと考えました。ページネーションを入力します。オブジェクトに対してクエリを実行するとき、nextPageToken利用可能なデータがさらにある場合、サーバーはフィールドにデータを入力します。トークンは、フィルター、制限、および orderBy 情報をカプセル化します。便宜上、 a はnextPageUrlすでにトークンが追加された状態で結果セットに含まれています。コンシューマは、nextPageUrlこのフィールドとトークンが として返されるまでnull、 でデータをプルし続けることができます。その時点でデータはなくなります。
ページネーションを使用すると、ユーザーは最大 100,000 件のレコードを取得できます。各ページには、最初のクエリで指定された制限に基づいて、最大 1000 件のレコードを含めることができます。データ量がこの制限を超える場合は、エクスポート API に移行することをお勧めします。
JSON と REST ネイティブ
Account Engagement API のバージョン 3 および 4 を使用したことがある場合は、XML がデフォルトの出力標準であり、ユーザーが必要に応じて JSON をリクエストする必要があることを覚えているでしょう。もうない！バージョン 5 はデフォルトで JSON をサポートします。
舞台裏では、本当の改善が起こっています。古いバージョンでは、ユーザーが要求した形式に関係なく、すべての要求に対して実際に XML を構築していました。応答を送信する前に、必要に応じて XML が JSON に変換されます。変換プロセスでは、一部の XML エントリは文字列として処理され、その他は JSON タイプとして処理されました。このプロセスは脆弱であり、不完全な変換が無効な JSON を引き起こす可能性があるエッジケースにつながりました。訪問者のようなオブジェクトに対するボットの送信には、変換中に問題を引き起こす広範なデータが含まれる可能性があるため、予想される動作を変更しない方法でこれを修正することは困難であることが判明しました。
最善の解決策は、JSON をゼロから始めることでした。そのため、私たちはまさにそれを実行しました。すぐに使える JSON タイプのサポートの最終的な効果により、呼び出し元は Pardot エンドポイントを Apex と統合しやすくなります。