サービスについて
ロサンゼルスのアメリカ企業であるクライアントは、音楽業界でのマーケティングに注力しています。 そのサービスは、角を曲がったギャングから世界クラスのスターまで、さまざまな規模のチームの複雑な広告キャンペーンをサポートします。
実際、当社の顧客サービスは、特定の業界の視聴者の行動の詳細を考慮に入れて、レコード会社から投資を集めることに成功した専門のマーケティングプラットフォームを開発するスタートアップです。 このプラットフォームでは、かつて特定のチームに関心を示していたユーザーの行動を分析することで、広告をターゲティングできます。 リソースの主なユーザーは、ミュージシャンと産業労働者（マネージャー、レコード会社の従業員、コンサート主催者など）です。
プロジェクトが開始される頃には、サービスはすでに機能しており、市場で一定の地位を獲得することができました。 ただし、特に機能の一部がパートナーサービスを通じて実装されているため、ビジネスの基本的な仮説をテストしたのはむしろプロトタイプでした。 本格的なアーキテクチャを作成するために開発に接続しましたが、GDPRはすべての変換を開始した非常に推進力でした。 私たちのタスクは、既存のサービスを更新するだけでなく、新しい法律でサービスを再構築し、更新してより統一されたユーザーインターフェイスにすることでした。
実装
プロジェクト全体はいくつかの段階に分けられました。
最初の段階で、以前PHPで機能していた部分（リンク短縮サービスと認証サービス）をゼロから書き直しました。
リンク短縮サービスは、すべての登録ユーザーが無料で利用できる機能の一部であり、顧客を会社の有料サービスに引き付けるために使用されます。 このサービスでは、長いリンクを短い形式にリンクして、ソーシャルネットワークに公開することができます。 同時に、ジオターゲティングなどを設定してリンクをカスタマイズできます。ユーザーが来た国に応じて、さまざまな着陸地を表示できます。
バックエンドの更新には、OpenJDK 1.8、Kotlin、Spring boot / data / webを使用しました。これは、高負荷を想定しないプロジェクトの標準フレームワークです。 ちなみに、このプロジェクトで初めてKotlinを「戦闘中」に試してみましたが、その構文により、開発を大幅にスピードアップすることができました。 間違いなく、他のプロジェクトで使用します。
認可サービスと短縮サービスのデータベースは、第1段階で実装され、PostgreSQLに基づいて構築されています。リレーショナルデータストレージモデルは、これらの問題を解決するのに適しています。
第二段階では、広告キャンペーンの管理を引き受けました。 クライアントプラットフォームのこの機能も以前に存在していましたが、パートナーのサービスを使用していたため、料金を支払う必要がありました。 現在、顧客のプラットフォームは、インフラストラクチャを管理する必要があるところまで成長しています。 サードパーティとは異なり、独自のサービスは正しい方向に開発するのがはるかに簡単であり、必要な変更をすばやく行います。
プロジェクトのこの部分では、キャンペーンマネージャー用の外部APIのみを実装しました。 しかし、第3段階でこのモジュールを開発しました。APIを完成させ、キャンペーンマネージャー用の本格的なUIを作成しました。
並行して、訪問者データの収集を制御する独自の小さなDMP（データ管理プラットフォーム）を開発しました。 DMPデータはMongoDBに格納されます。これは、このデータベースの将来の水平スケーリングに備えて土台を残すことにしたためです。 現在、DMPは1秒間に最大2,000リクエスト（ピーク時）を処理しますが、約1テラバイトのデータの保存に注力しています。 このようなボリュームはPostgreSQLで保存できましたが、長期的にはスケーリングに多大な努力を払う必要がありました。
同じMongoDBがキャンペーンマネージャーデータベース（キャンペーンDB）で使用されています-ここでは、ドキュメント指向のデータベースのモデルがよく思い付きました。 キャンペーンは単一のエンティティとして機能し、拡張できます。
すべてのキャッシュはRedisで機能します。
フロントエンド：Angular 5、TypeScript、HTML5、Sass、Node.js、npm、Angular CLI。
プロジェクトの最後の段階で、顧客システムと主要パートナーのサービスの統合を完了し、会社のミュージシャンの膨大なベースへのアクセスを開放し、ユーザー数の増加を確実にします。
プロジェクトにはいくつかの困難がありました。 顧客は、サービスの運用中に蓄積されたユーザーデータと登録を保存し、モデルを少し変更したいと考えていました。 アーキテクチャの変更と並行して、登録を転送し、その原則を変更しました-ログインとしてのユーザー名から電子メールへ、同じ電子メールアドレスを持つユーザーの数の制限により多くの眠れぬ夜をもたらしました。 システムの権利のモデルが変更されました。 以前は、サービスは2レベルのモデルに従って機能していましたが、制限なしで権利のモデルを実装しました（制限された権利を発行する機能を含む）。
同時に、機能が拡張されました。 たとえば、ある段階でマルチストアが表示され、特定の楽曲への短いリンクをクリックするエンドビジターのために、これらの楽曲が合法的に購入または聴くことができるサービスのリストを含むページを設定できます。
GDPRについて個別に言う価値があります
クライアントの主な市場は米国ですが、同社が失いたくないトラフィックの約10％はヨーロッパからのものでした。 新しい規制が施行されてから（2018年5月25日）、そのターゲティングは無効になりました。 弁護士と相談した後、GDPRと矛盾しないようにサービスを構築し、8月16日から再びターゲット設定を開始しました。
正直なところ、2週間のグループ全体で規制の複雑さを調査しました。 この段階での困難は、文言の一般的なあいまいさにより、これまで法執行の慣行がなかったことでした。それを正しく行う方法と間違っていることを示すことができる実際のケースです。 ただし、現在（独自の調査と弁護士との協議の後）、ソリューションの実装されたアーキテクチャに自信を持っています。
このサービスのロジックは、特定の視聴者への短いリンクをたどるユーザーを追加することを意味しているため、後で広告を表示できます。 GDPRに関しては、ユーザーの明示的な同意なしにこれを行うことはできません。 また、同意のリクエストを実装しました。ページの下部にあるリンクをクリックすると、質問と2つのボタンが付いたプレートが表示されます。 IPがヨーロッパに属するユーザーに対してリクエストが開かれ、そのレスポンスはCookieの形式で保存されるため、訪問者は毎回ボタンを押す必要がありません。
ユーザーの同意がない場合（Cookieなど）、ピクセルを表示しません。 サービスの一般的な統計では、訪問の事実がカウントされますが、ユーザーデータは収集されず、考慮されません。
GDPRはアーキテクチャ上の制限を課します-個人データは正しく収集されるだけでなく、安全に保存される必要があります。 私たちの場合、これらの制限は、実装されたDMP（匿名データを匿名で保存するという事実にもかかわらず、匿名データの匿名化のみを許可する）と認可サービスデータベースに適用されます。 私たちのアーキテクチャでは、これらのベースは明らかに別々のブロックに割り当てられています。 規制に従って、これらの「機密」モジュールへのサードパーティのアクセスは当然制限されています。
対応するサービスのみが認証データベースにアクセスできます。 他のすべてのサービスは、プラットフォームユーザーの個人データについては何も知りません。承認サービスからの検証のみが必要です。
DMPデータベースには、同名のサービスのみが含まれます。 同時に、データベースからはオーディエンスデータの集計のみが返されますが、データ自体は返されません。 これらの集計は、音楽業界のサービスのユーザーがパーソナルダッシュボードで受け取る分析の基礎を形成します。
ユーザーデータをアップロードおよび削除するための必須手順もあります。 ユーザーが本当に合法的に自分のデータを要求していることを確認する方法について質問がありました。 そして、ユーザーが保存したCookieを検証の要素として使用します。
プロジェクトは最近完了したため、数値結果について話すのは時期尚早です。
記事の著者：ニコライ・エレミン
PS Runetのいくつかのサイトで記事を公開しています。 VK 、 FB、または電報チャネルのページを購読して、すべての出版物やその他のMaxilectニュースについて学びます。