Google Workspaceの連絡先をデータ損失なしで同期する方法

Google Workspaceの連絡先同期機能は、GoogleコンタクトとCRM間で連絡先をスケジュールに基づいてコピーします。重複は通常、設定された一致キーを使用して2つのシステムが同一人物を識別できなかった場合に発生します。また、競合ルールによって新しい値が上書きされた場合や、削除がシステム間で伝播した場合にもデータが失われる可能性があります。Googleコンタクトは過去30日間の変更を元に戻せるため、これが実質的な復旧期間となります。

連絡先の同期によってランダムなデータ損失が発生することは稀です。問題のほとんどは、処理過程における3つの予測可能なポイント、すなわちレコードの照合方法、競合する編集の解決方法、および削除が反映されるかどうかから生じます。

多くのチームは、同期を簡単な設定作業として捉えています。Google Workspaceに接続し、連絡先フィールドを選択し、方向を選んで、オンにするだけです。問題はたいてい後になって発生します。連絡先リストが倍増していたり、CRMで修正した電話番号がGoogleコンタクトの古い値に置き換えられていたりすることに誰かが気づいたときです。

これらの結果は必ずしもソフトウェアの不具合とは限りません。多くの場合、同期ルールの設定方法に直接起因しています。より安全なアプローチは、各同期サイクル中にコネクタが何を行うかを理解し、重要なフィールドをどのシステムが制御すべきかを特定し、最初の一括同期の前にリカバリポイントを作成することです。

連絡先同期の仕組み

Google Workspaceの連絡先同期は、2つの異なるシステム間でレコードを比較して更新します。通常は即座に実行されるのではなく、スケジュールに基づいて実行されるため、各サイクルで前回の実行以降に変更された内容を確認し、設定されたルールを適用します。

同期サイクルは5つのステップで構成されます。

コネクタは変更をチェックします – 前回の処理以降に作成、編集、または削除された連絡先を特定します。コネクタによっては、これらのチェックは即時ではなく、数分ごとに実行される場合があります。
記録と一致する – 変更された連絡先ごとに、コネクタは他のシステムで対応するレコードを検索します。この比較に使用されるフィールドはマッチキーと呼ばれ、メールアドレスがよく使用されます。
それはフィールドをマッピングします – コネクタは、2つのシステム間でどのフィールドが対応しているかを決定します。名前、メールアドレス、電話番号、会社名、役職などは、直接対応するフィールドが存在する場合があります。対応先が特定されていないフィールドは転送されません。
紛争を解決する – 次の同期の前に両方のシステムで同じ連絡先が変更された場合、競合ルールによってどちらの値が保持されるかが決定されます。
変更内容を書き込みます – コネクタは、選択された同期方向と権限に従って、結果として生じる変更を適用します。

重要な点は マッチングと紛争解決は別々の問題であるマッチングは、コネクタが2つのレコードが同一人物に属すると判断するかどうかを決定します。競合解決は、同一人物であると判断された場合に、どちらの値が優先されるかを決定します。

重要な注意： 同期は、それぞれが独自の記録を保持する2つのシステム間でデータをコピーします。これは、 Google Workspace CRM連携顧客情報の共有を基盤として構築されています。CRMをまだ選定中であれば、この点は重要です。なぜなら、顧客情報を共有することで、複数のシステム間で照合する必要のある連絡先データの量を削減できるからです。

何が移転されるのか？

連絡先同期では、必ずしもすべてのフィールドが一方のシステムから他方のシステムに転送されるとは限りません。

データ・タイプ	Googleの連絡先	CRM	典型的な同期結果
名前	はい	はい	通常地図に載っている
メールアドレス	はい	はい	通常はマッピングされ、マッチングに使用される
電話番号・携帯番号	はい	はい	通常地図に載っている
会社	はい	はい	通常地図に載っている
職名	はい	はい	よく地図に載っている
ラベル	はい	不定	譲渡できない場合があります
鉛源	いいえ	はい	通常はCRMに保持されます
取引履歴	いいえ	はい	CRMに残ります
カスタム CRM フィールド	いいえ	はい	通常はCRMに保持されます

マッピングされていないフィールドは必ずしも削除されるわけではありません。単に、もう一方のシステムにマッピング先がないだけです。問題となるのは、チームが両方のシステムにフィールドが存在すると想定していたにもかかわらず、実際にはマッピングに含まれていなかったことが判明した場合です。

一方向同期と双方向同期

同期方向は、どちらのシステムがもう一方のシステムを変更できるかを決定します。この決定は、個々のフィールドマッピングを検討する前に行うべきです。なぜなら、競合する編集が発生するかどうかを決定するからです。

基準	一方向同期	双方向同期
変化の方向性	出発地から目的地まで	両方のシステム
紛争	両システム間では	可能
重複レコード	まだ可能	可能
目的地編集	上書き可能	逆方向に伝播する
セットアップの複雑さ	低くなる	より高い
に最適	マスターとして機能するシステムが1つ	両方のシステムを積極的に活用しているチーム

一方のシステムが明確な情報源である場合、一方向同期の方が安全です。
例えば、Googleコンタクトが単にCRMへのデータ入力に使用されている場合、CRMの編集内容をGoogleに反映させる理由はほとんどありません。

双方向同期は、従業員が両方のシステムで連絡先をきちんと更新する場合に有効です。
また、新たな要件も生じます。それは、両方のシステムに同じ連絡先の異なるバージョンが含まれている場合にどうするかを決定するためのルールが必要になるということです。

重要な違いは単純です。一方向同期は競合リスクを低減しますが、重複リスクを完全に排除するわけではありません。コネクタが既存の連絡先と照合できなかった場合、レコードが重複する可能性があります。

同期処理が重複データやデータ損失を引き起こす理由

連絡先同期の問題のほとんどは、レコードのマッチング失敗、編集内容の競合、削除情報の伝播という3つのメカニズムに起因します。それぞれに異なる解決策が必要となるため、同期後に重複レコードを単純にマージするだけでは根本的な問題は解決しません。

マッチキー

マッチキーとは、コネクタが2つのレコードが同一人物を表しているかどうかを判断するために使用するフィールドです。

メールアドレスは比較的固有であるため、一般的に使用されています。しかし、常に存在するとは限らず、一貫性がないという問題があります。

試合が失敗する

両方のシステムに存在する連絡先について考えてみましょう。

Google の連絡先: [メール保護]
CRM： [メール保護]

人間であれば、両方のレコードがジョン・スミスのものであるとすぐに認識できる。しかし、メールアドレスの完全一致を使用するコネクタは、そのような推測ができない。2つの異なる値を認識し、2つ目のレコードを作成する可能性がある。

同様の問題は、次のような場合にも発生します。

1件の記録にはメールアドレスが記載されていません。
一方のシステムでは仕事用のメールアドレスが使用され、もう一方のシステムでは個人用のメールアドレスが使用される。
電話番号はさまざまな形式を使用します。
このコネクタは、ユーザーが頻繁に編集するフィールドに対応しています。
同期機能が有効になる前から、重複データは既に存在していました。

電話番号のフォーマットによっては、特に紛らわしい結果が生じる場合があります。例えば、+44 20 7946 0958 と 02079460958 は同じ番号を表している可能性がありますが、コネクタが保存されている文字列を厳密に比較すると、一致しない場合があります。

マージする前にキーを修正してください

重複データの統合は、マッチングの問題を修正した後にのみ有効です。

マッチキーが依然として不整合な場合、次回の同期で、先ほど削除した重複レコードが再作成される可能性があります。正しい手順は次のとおりです。

マッチングが失敗した理由を特定する → フィールドを標準化する → 既存の重複をマージする → 制御された同期を実行する。

大規模なデータベースの場合は、双方向同期を有効にする前に、選択した一致キーが欠落しているレコードの数を確認することも重要です。

紛争解決

コネクタが2つのレコードを同じ連絡先として認識したが、次の同期前に両方のシステムが編集されたため、異なる値が検出された場合に競合が発生します。

一般的なアプローチは次のとおりです。

抵触規則	何が起こるのですか	主なリスク
最後に書き込んだ人が勝ち	最新の編集内容が保持されます	以前の有用な修正は上書きされる可能性があります
記録システム	1つのシステムがフィールドを制御する	他のシステムでの変更は保持されない場合があります
フィールドレベルのルール	分野によって異なるルールが適用される	さらなるセットアップとメンテナンスが必要

最終書き込み優先は便利ですが、気づかないうちに変更が加えられる可能性があります。例えば、午前9時にCRMで電話番号を修正した従業員が、午前10時にGoogleで同じ連絡先を古い電話番号を使って編集した場合、後から編集された内容が修正内容を上書きしてしまう可能性があります。

売上や顧客サービスに影響を与える分野については、代わりに記録システムを指定することを検討してください。 CRMデータベース構造アドレス帳の編集によって上書きされるべきではない情報が含まれている可能性があります。

削除伝播

削除は、連絡先自体には表示されない情報も削除できるため、別途検討する必要がある。

双方向通信の場合、Googleで連絡先を削除すると、CRMの対応する連絡先も削除される可能性があります。CRMの記録にメモ、活動履歴、取引情報、顧客記録へのリンクなどが含まれている場合、名前と電話番号が失われるよりも大きな影響が生じます。

行動	潜在的な結果
連絡先の編集	別のシステムが新しい値を受け取る
連絡先を作成	別のシステムが対応するレコードを作成する
連絡先をマージ	1つのレコードが削除または変更される場合があります
連絡先を削除	削除は伝播する可能性がある
両側を入れ替える	紛争ルールは存続価値を決定する

コネクタで削除伝播を無効化できる場合は、ワークフローで特に必要とされない限り、無効化したままにしておくことを検討してください。

同期を安全に設定する

最も効果的な制御策は、最初の同期前に適用されるものです。数千件もの連絡先が複製または上書きされてしまうと、元のデータと同期によって生成された変更を区別する必要が生じるため、クリーンアップ作業は著しく困難になります。

最初のサイクルを開始する前に、これらのチェックを完了してください。

両方のシステムをエクスポートする： GoogleコンタクトとCRMのデータをCSV形式でエクスポートし、両システムとは別の場所に保存しておきましょう。こうすることで、最初の同期が予期せぬ動作をした場合の復旧ポイントを確保できます。
既存の重複を削除する: 既に重複データが含まれているデータベースを同期すると、照合が難しくなり、問題がさらに悪化する可能性があります。
マッチキーのカバー範囲を確認してください： マッチングに使用する予定のフィールド（特にメールアドレス）が欠落している連絡先がいくつあるかを確認してください。
電話番号を標準化する： フォーマットの違いによって照合が妨げられないよう、両方のシステムで同じフォーマットを使用してください。
一方向同期から始めましょう： まずCRMにデータを入力し、結果を検証してから、変更が双方向に反映されるようにする。
削除伝播を無効にする： 明確な運用上の理由がない限り、削除されたデータがシステム間で自動的に移動しないようにする。
少人数グループでテストを実施する： データベース全体ではなく、まずは20件の連絡先から始めましょう。テストグループがあれば、フィールドマッピングやマッチングルールの誤りを明らかにするのに十分です。

最初のサイクル後に結果を確認してください

最初の同期レポートが「完了」と表示されても、確認を止めないでください。コネクタによっては、最初の転送後に追加の調整サイクルを実行するものがあります。最初の実行直後は正しく見えるデータベースでも、次のスケジュールされたサイクルでレコードが処理される際に再び変更される可能性があります。

より安全な検査方法は以下のとおりです。

最初のサイクル → レコードを検査 → 別のサイクルを待つ → 再度検査 → 同期グループを拡張。

これをスキップしないでください: テストグループで重複レコードが発生した場合は、展開する前に同期を停止してください。この段階でマッチキーとフィールドのマッピングを修正する方が、数千件のレコードにわたって同じ問題を修正するよりもはるかに簡単です。

同期不良からの復旧

同期処理によって既に連絡先が上書きまたは削除されている場合は、クリーンアップを試みる前に同期を停止してください。そうしないと、コネクタは、その影響を元に戻そうとしている間も同じルールを適用し続ける可能性があります。

復旧プロセスは以下の順序で進める必要があります。

同期を無効にします。
両システムの現在の状態をエクスポートします。
望ましくない変化が始まった時期を特定する。
利用可能な復旧履歴またはバックアップを使用してください。
重複した記録や誤った記録を修正する。
同期設定を修正してください。
フルデータベースに再接続する前に、もう一度小規模なテストを実行してください。

Googleが復元できるもの

Google コンタクトは、 変更を元に戻します 過去30日間の特定の時点の状態に連絡先を復元できるオプションがあります。Googleによると、この復元機能を使用すると、その期間中の指定した時点の連絡先リストの状態に戻すことができるとのことです。

この30日間という期間は、Google側で大規模な連絡先変更を元に戻すことができる期間を制限するため重要です。復元する前に、現在の連絡先をエクスポートしてください。選択した復元ポイント以降に追加された連絡先は、古い状態を復元すると削除される可能性があるためです。

Googleはまた、ゴミ箱から完全に削除された連絡先は、この復元プロセスでは復元できないと述べている。

30日間の猶予期間でカバーされないもの

Googleの復元ウィンドウはGoogleコンタクトに適用されます。CRMで上書きまたは削除されたデータは自動的に復元されません。

例えば、同期によってCRMの電話番号が変更され、CRMにそのフィールドのバージョン履歴がない場合、Googleの元に戻す機能を使っても必ずしもCRMの値が復元されるとは限りません。

CRMレコードに添付された情報にも同じことが言えます。連絡先の名前とメールアドレスはエクスポートから簡単に復元できるかもしれませんが、関連するメモ、活動、商談、顧客とのやり取りなどは、CRMがそれらを個別に保存していない限り復元できない可能性があります。

回復ソース	回復に役立つもの	制限
Google連絡先の取り消し	以前のGoogle連絡先状態	30日限定
Google連絡先のゴミ箱	最近削除した連絡先	完全に空になったゴミは復元できません
CRMごみ箱	削除されたCRMレコード	CRMによって顧客維持率は異なります
CRM監査/履歴	以前のフィールド値	CRMと有効化されたトラッキングに依存します
CSVエクスポート	連絡先データのスナップショット	エクスポートされたもののみが含まれています

既に問題が発生している場合： 重複データのマージやレコードの復元を行う前に、同期をオフにしてください。その後、現在の状態をエクスポートし、問題が発生した時期を特定し、データを修復し、同期ルールを修正してから、制御されたテストを実施した後にのみ再接続してください。そうしないと、修正作業中に同じ不具合のある設定が再び発生する可能性があります。

Vtiger Oneとの連絡先の同期

Vtiger Oneは、Google WorkspaceのデータとCRMレコードを連携させることで、チームが顧客レコードを完全に別々に管理することなく、連絡先、メール、カレンダー、ファイル、会議などをまとめて操作できるようにします。

重要な違いは、連絡先がCRMに登録された後に何が起こるかという点です。CRMの連絡先は、営業機会、サポート案件、活動、メモ、顧客とのやり取りなどと関連付けることができます。こうしたコンテキストは、アドレス帳に保存されている基本的な連絡先情報とは異なります。

そのため、連絡先の同期は、単に2つのアプリ間の接続としてではなく、データ管理プロセスとして扱う必要があるのです。

その顧客関係管理 Googleの連絡先に名前、電話番号、メールアドレスしか含まれていない場合でも、記録は有用であり続けるはずです。リード管理プロセスアドレス帳には含まれていない販売に関する文脈情報を追加する。

照合するコピーの数が減る

顧客情報の独自のコピーを保持するシステムが増えるほど、維持しなければならない照合ルールと競合ルールも増える。

An オールインワン CRM プラットフォーム営業、マーケティング、サポートチームが同じ顧客レコードを共有することで、重複作業を削減できます。Google Workspaceは生産性向上レイヤーとして機能し、CRMは顧客履歴とビジネス活動を管理するシステムとして機能します。

実用的設定チェック

VtigerでGoogle Workspaceを設定する場合は、一括同期を有効にする前に、以下の項目を確認してください。

レビュー Googleアプリ同期オプションを選択し、チームが実際に使用するサービスのみを有効にします。
確認する Google CRMとの連携最初の同期前の方向。
Apply CRMセキュリティ管理統合を管理またはトリガーできるユーザー向け。
初めて大量に輸入する場合は、 CRM移行計画日常的な環境の変化というよりは、運動に近い。
Gmailがチームのワークフローの中心である場合、 Google向けに構築されたCRM 従業員が更新する必要のある個別のシステムの数を削減します。

目的は、すべてのシステム連携を排除することではありません。顧客情報の各項目がどのシステムによって管理されているのか、どの項目がシステム間で移動できるのか、そして2人のユーザーが同じレコードを編集した場合に何が起こるのかを明確にすることです。

Fよくある質問

私のCRMはなぜ重複した連絡先を作成し続けるのでしょうか？

同期処理で受信したレコードを既存の連絡先と照合できないためです。照合には通常メールアドレスが使用されるため、メールアドレスのない連絡先、システムごとに異なるメールアドレスを持つ連絡先、または書式が統一されていない連絡先は、新規レコードとして扱われる可能性があります。

一方向同期は重複を防ぐことができますか？

いいえ。一方向同期は、両方のシステムが同じレコードを編集することによって発生する競合を防ぎますが、マッチングの失敗を防ぐものではありません。コネクタが既存の連絡先を識別できない場合、宛先システムに重複した連絡先が作成される可能性があります。

両方のシステムで連絡先が変更された場合、どちらのシステムが優先されるのでしょうか？

結果は、コネクタに設定されている競合ルールによって異なります。一般的なデフォルト設定は「最終書き込み優先」で、最新の編集内容が以前の値を上書きします。特定のフィールドを1つのシステムで制御する必要がある場合は、コネクタがサポートするフィールドについて、そのシステムを真の情報源として設定してください。

同期がうまくいかなかった場合、連絡先を復元できますか？

Google コンタクトでは、過去 30 日以内に行われた変更を元に戻すことができます。ゴミ箱から完全に削除された連絡先は、Google の元に戻す機能では復元できません。CRM で上書きまたは削除されたデータを復元できるかどうかは、その CRM のごみ箱、監査履歴、バージョン履歴、または利用可能なバックアップによって異なります。

削除同期をオフにした方が良いでしょうか？

ほとんどのチームにとって、ワークフローで特に必要とされない限り、削除の伝播を無効にする方が安全な選択肢です。そうしないと、削除がGoogleからCRMに伝播し、レコードとその関連するビジネス履歴が削除されてしまう可能性があります。

連絡先同期を有効にする前に、どのような準備が必要ですか？

両方のシステムをエクスポートし、既存の重複を削除し、マッチキーの適用範囲を確認し、電話フォーマットを標準化し、一方向同期から開始し、削除の伝播を無効にし、データベース全体を同期する前に、少数のグループで最初のサイクルをテストしてください。

同期が最初は正しく行われたように見えたのに、なぜ重複データが出現したのでしょうか？

一部のコネクタは、後続のスケジュールされたサイクルで調整処理を実行します。そのため、最初の実行は成功したように見えても、後続のサイクルで追加のレコードが処理される場合があります。同期グループを拡張する前に、別のスケジュールされたサイクル後に再度テストしてください。

連絡先同期におけるマッチキーとは何ですか？

マッチキーとは、コネクタが一方のシステムのレコードと他方のシステムのレコードが同一人物を表しているかどうかを判断するために使用するフィールドです。一般的にはメールアドレスが使用されます。このフィールドが欠落しているか、内容が一致しない場合、コネクタは既存の連絡先を更新する代わりに、新しい連絡先を作成する可能性があります。

Google Workspaceの連絡先同期：重複とデータ損失を回避する方法