অ্যাট্রিবিউশন রিপোর্টিং এপিআই ডেভেলপারের গাইড, অ্যাট্রিবিউশন রিপোর্টিং এপিআই ডেভেলপারের গাইড, অ্যাট্রিবিউশন রিপোর্টিং এপিআই ডেভেলপারের গাইড

বিকাশকারী পূর্বরূপ বিটা

আপনি Android ডকুমেন্টেশনের গোপনীয়তা স্যান্ডবক্সের মাধ্যমে পড়ার সময়, আপনি যে প্রোগ্রামটির সাথে কাজ করছেন সেটি নির্বাচন করতে বিকাশকারী পূর্বরূপ বা বিটা বোতামটি ব্যবহার করুন, কারণ নির্দেশাবলী পরিবর্তিত হতে পারে।

---

অ্যাট্রিবিউশন রিপোর্টিং API ক্রস-পার্টি ব্যবহারকারী শনাক্তকারীর উপর নির্ভরতা সরিয়ে উন্নত ব্যবহারকারীর গোপনীয়তা প্রদান করার জন্য এবং অ্যাপ জুড়ে অ্যাট্রিবিউশন এবং রূপান্তর পরিমাপের জন্য মূল ব্যবহারের ক্ষেত্রে সমর্থন করার জন্য ডিজাইন করা হয়েছে। এই বিকাশকারী নির্দেশিকা বর্ণনা করে যে কীভাবে বিজ্ঞাপনের ক্লিক, ভিউ এবং রূপান্তরগুলি নিবন্ধন করতে অ্যাট্রিবিউশন রিপোর্টিং এপিআইগুলি কনফিগার এবং পরীক্ষা করতে হয় যেগুলি এই ধরনের ইভেন্টগুলির জন্য প্রাসঙ্গিক ট্রিগার এবং উত্সগুলি নিবন্ধন করে।

এই নির্দেশিকা আপনাকে শেখায় কিভাবে সার্ভার এন্ডপয়েন্ট সেট আপ করতে হয় এবং একটি ক্লায়েন্ট অ্যাপ তৈরি করতে হয় যা এই পরিষেবাগুলিকে কল করে৷ ডিজাইন প্রস্তাবে অ্যাট্রিবিউশন রিপোর্টিং API এর সামগ্রিক ডিজাইন সম্পর্কে আরও জানুন।

মূল শর্তাবলী

• অ্যাট্রিবিউশন সোর্স ক্লিক বা ভিউ উল্লেখ করে।
• ট্রিগার হল ইভেন্ট যা রূপান্তরের জন্য দায়ী করা যেতে পারে।
• প্রতিবেদনে একটি ট্রিগার এবং সংশ্লিষ্ট অ্যাট্রিবিউশন উত্স সম্পর্কে ডেটা থাকে৷ এই প্রতিবেদনগুলি ট্রিগার ইভেন্টগুলির প্রতিক্রিয়া হিসাবে পাঠানো হয়। অ্যাট্রিবিউশন রিপোর্টিং API ইভেন্ট-স্তরের রিপোর্ট এবং সমষ্টিগত রিপোর্ট সমর্থন করে।

আপনি শুরু করার আগে

অ্যাট্রিবিউশন রিপোর্টিং API ব্যবহার করতে, নিম্নলিখিত বিভাগে তালিকাভুক্ত সার্ভার-সাইড এবং ক্লায়েন্ট-সাইড কাজগুলি সম্পূর্ণ করুন৷

অ্যাট্রিবিউশন রিপোর্টিং API এন্ডপয়েন্ট সেট আপ করুন

অ্যাট্রিবিউশন রিপোর্টিং API-এর জন্য শেষ পয়েন্টগুলির একটি সেট প্রয়োজন যা আপনি একটি পরীক্ষা ডিভাইস বা এমুলেটর থেকে অ্যাক্সেস করতে পারেন৷ নিম্নলিখিত সার্ভার-সাইড কাজের জন্য একটি শেষ পয়েন্ট তৈরি করুন:

• একটি অ্যাট্রিবিউশন উত্স নিবন্ধন করুন (দেখুন বা ক্লিক করুন)
• একটি ট্রিগার নিবন্ধন করুন (রূপান্তর)
• ইভেন্ট-স্তরের রিপোর্ট গ্রহণ করুন
• সমষ্টিগত প্রতিবেদন গ্রহণ করুন

প্রয়োজনীয় শেষ পয়েন্ট সেট আপ করার বিভিন্ন পদ্ধতি আছে:

• উঠতে এবং চালানোর দ্রুততম উপায় হল আমাদের নমুনা কোড সংগ্রহস্থল থেকে একটি মক বা মাইক্রোসার্ভিসেস প্ল্যাটফর্মে OpenAPI v3 পরিষেবার সংজ্ঞা স্থাপন করা। আপনি পোস্টম্যান , প্রিজম , বা অন্য কোন মক সার্ভার প্ল্যাটফর্ম ব্যবহার করতে পারেন যা এই বিন্যাসটি গ্রহণ করে৷ প্রতিটি এন্ডপয়েন্ট স্থাপন করুন এবং আপনার অ্যাপে ব্যবহারের জন্য URI-এর ট্র্যাক রাখুন। রিপোর্ট ডেলিভারি যাচাই করতে, মক বা সার্ভারহীন প্ল্যাটফর্মে পূর্বে করা কলগুলি দেখুন।
• স্প্রিং বুট -ভিত্তিক কোটলিন নমুনা ব্যবহার করে আপনার নিজস্ব স্বতন্ত্র সার্ভার চালান। আপনার ক্লাউড প্রদানকারী বা অভ্যন্তরীণ অবকাঠামোতে এই সার্ভারটি স্থাপন করুন।
• আপনার বিদ্যমান সিস্টেমে শেষ পয়েন্টগুলিকে একীভূত করতে উদাহরণ হিসাবে পরিষেবা সংজ্ঞাগুলি ব্যবহার করুন৷

দ্রষ্টব্য: ইউআরআই নথিভুক্ত করার বিষয়ে আরও তথ্যের জন্য একটি গোপনীয়তা স্যান্ডবক্স অ্যাকাউন্টের জন্য তালিকাভুক্তি দেখুন। উদাহরণ এন্ডপয়েন্ট নাম নিম্নলিখিত বিভাগে প্রদর্শিত হয়.

উৎস নিবন্ধন গ্রহণ করুন

এই শেষ পয়েন্টটি নিম্নলিখিতগুলির মতো একটি URI থেকে ঠিকানাযোগ্য হওয়া উচিত:

https://adtech.example/attribution_source

যখন একটি ক্লায়েন্ট অ্যাপ একটি অ্যাট্রিবিউশন উৎস নিবন্ধন করে , তখন এটি এই সার্ভারের শেষ পয়েন্টের জন্য URI প্রদান করে। অ্যাট্রিবিউশন রিপোর্টিং API তারপর একটি অনুরোধ করে এবং নিম্নলিখিত শিরোনামগুলির মধ্যে একটি অন্তর্ভুক্ত করে:

• ক্লিক ইভেন্টের জন্য:

  Attribution-Reporting-Source-Info: navigation
  

• ইভেন্ট দেখার জন্য:

  Attribution-Reporting-Source-Info: event
  

নিম্নলিখিতগুলির সাথে প্রতিক্রিয়া জানাতে আপনার সার্ভারের শেষ পয়েন্ট কনফিগার করুন:

// Metadata associated with attribution source.
Attribution-Reporting-Register-Source: {
  "destination": "[app package name]",
  "web_destination": "[eTLD+1]",
  "source_event_id": "[64 bit unsigned integer]",
  "expiry": "[64 bit signed integer]",
  "event_report_window": "[64-bit signed integer]",
  "aggregatable_report_window": "[64-bit signed integer]",
  "priority": "[64 bit signed integer]",
  "filter_data": {
    "[key name 1]": ["key1 value 1", "key1 value 2"],
    "[key name 2]": ["key2 value 1", "key2 value 2"],
    // Note: "source_type" key will be automatically generated as
    // one of {"navigation", "event"}.
  },
  // Attribution source metadata specifying histogram contributions in aggregate
  // report.
  "aggregation_keys": {
    "[key1 name]": "[key1 value]",
    "[key2 name]": "[key2 value]",
  },

    "debug_key": "[64-bit unsigned integer]",
    "debug_reporting": [boolean]
}
// Specify additional ad tech URLs to register this source with.
Attribution-Reporting-Redirect: <Ad Tech Partner URI 1>
Attribution-Reporting-Redirect: <Ad Tech Partner URI 2>

এখানে নমুনা মান যোগ করা একটি উদাহরণ:

Attribution-Reporting-Register-Source: {
  "destination": "android-app://com.example.advertiser",
  "source_event_id": "234",
  "expiry": "259200",
  "event_report_window": "172800",
  "aggregatable_report_window": "172800",
  "priority": "5",
  "filter_data": {
    "product_id": ["1234"]
  },
  "aggregation_keys": {
  // Generates a "0x159" key piece named (low order bits of the key) for the key
  // named "campaignCounts".
  // User saw an ad from campaign 345 (out of 511).
    "campaignCounts": "0x159",

  // Generates a "0x5" key piece (low order bits of the key) for the key named
  // "geoValue".
  // Source-side geo region = 5 (US), out of a possible ~100 regions.
    "geoValue": "0x5",
  },
  // Opts in to receiving verbose debug reports
  "debug_reporting": true
}

Attribution-Reporting-Redirect:
https://adtechpartner1.example?their_ad_click_id=567
Attribution-Reporting-Redirect:
https://adtechpartner2.example?their_ad_click_id=890

দ্রষ্টব্য: সামঞ্জস্যপূর্ণ ফলাফলের জন্য, যে বৈশিষ্ট্যগুলি সাংখ্যিক মান যেমন source_event_id বা expiry প্রত্যাশা করে সেগুলিকে স্ট্রিং মান হিসাবে উদ্ধৃতিতে পাঠানো উচিত, যেমন উদাহরণগুলিতে নির্দেশ করা হয়েছে৷

যদি Attribution-Reporting-Redirects বিজ্ঞাপন প্রযুক্তি অংশীদারদের ইউআরআই থাকে, তাহলে অ্যাট্রিবিউশন রিপোর্টিং এপিআই প্রতিটি ইউআরআই-এর জন্য একই রকম অনুরোধ করে। প্রতিটি বিজ্ঞাপন প্রযুক্তি অংশীদারকে অবশ্যই একটি সার্ভার কনফিগার করতে হবে যা এই শিরোনামগুলির সাথে প্রতিক্রিয়া জানায়:

Attribution-Reporting-Register-Source: {
  "destination": "[app package name]",
  "web_destination": "[eTLD+1]",
  "source_event_id": "[64 bit unsigned integer]",
  "expiry": "[64 bit signed integer]",
  "event_report_window": "[64-bit signed integer]",
  "aggregatable_report_window": "[64-bit signed integer]",
  "priority": "[64 bit signed integer]",
  "filter_data": {
    "[key name 1]": ["key1 value 1", "key1 value 2"],
    "[key name 2]": ["key2 value 1", "key2 value 2"],
    // Note: "source_type" key will be automatically generated as
    // one of {"navigation", "event"}.
  },
  "aggregation_keys": {
    "[key1 name]": "[key1 value]",
    "[key2 name]": "[key2 value]",
  }
}
// The Attribution-Reporting-Redirect header is ignored for ad tech partners.

দ্রষ্টব্য: শুধুমাত্র যে বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্মটি API কল শুরু করে Attribution-Reporting-Redirect এ অংশীদারদের নির্দিষ্ট করতে পারে।

রূপান্তর ট্রিগার নিবন্ধন গ্রহণ করুন

এই শেষ পয়েন্টটি নিম্নলিখিতগুলির মতো একটি URI থেকে ঠিকানাযোগ্য হওয়া উচিত:

https://adtech.example/attribution_trigger

যখন একটি ক্লায়েন্ট অ্যাপ একটি ট্রিগার ইভেন্ট নিবন্ধন করে , তখন এটি এই সার্ভারের শেষ পয়েন্টের জন্য URI প্রদান করে। অ্যাট্রিবিউশন রিপোর্টিং API তারপর একটি অনুরোধ করে এবং নিম্নলিখিত শিরোনামগুলির মধ্যে একটি অন্তর্ভুক্ত করে:

নিম্নলিখিতগুলির সাথে প্রতিক্রিয়া জানাতে আপনার সার্ভারের শেষ পয়েন্ট কনফিগার করুন:

// Metadata associated with trigger.
Attribution-Reporting-Register-Trigger: {
  "event_trigger_data": [{
    // "trigger_data returned" in event reports is truncated to
    // the last 1 or 3 bits, based on conversion type.
    "trigger_data": "[unsigned 64-bit integer]",
    "priority": "[signed 64-bit integer]",
    "deduplication_key": "[signed 64-bit integer]",
    // "filter" and "not_filters" are optional fields which allow configuring
    // event trigger data based on source's filter_data. They consist of a
    // filter set, which is a list of filter maps. An event_trigger_data object
    // is ignored if none of the filter maps in the set match the source's
    // filter data.
    // Note: "source_type" can be used as a key in a filter map to filter based
    // on the source's "navigation" or "event" type. The first
    // Event-Trigger that matches (based on the filters/not_filters) will be
    // used for report generation. If none of the event-triggers match, no
    // event report will be generated.
    "filters": [{
      "[key name 1]": ["key1 value 1", "key1 value 2"],
      // If a key is missing from filters or source's filter_data, it won't be
      // used during matching.
      "[key name 2]": ["key2 value 1", "key2 value 2"],
    }],
    "not_filters":  [{
      "[key name 1]": ["key1 value 1", "key1 value 2"],
      // If a key is missing from not_filters or source's filter_data, it won't
      // be used during matching.
      "[key name 2]": ["key2 value 1", "key2 value 2"],
    }]
  }],
  // Specify a list of dictionaries that generates aggregation keys.
  "aggregatable_trigger_data": [
    // Each dictionary entry independently adds pieces to multiple source keys.
    {
      "key_piece": "[key piece value]",
      "source_keys": ["[key name the key piece value applies to]",
      ["list of IDs in source to match. Non-matching IDs are ignored"]]
      // filters/not_filters are optional fields similar to event trigger data
      // filter fields.
      "filters": [{
        "[key name 1]": ["key1 value 1", "key1 value 2"]
      }],
      "not_filters":  [{
          "[key name 1]": ["key1 value 1", "key1 value 2"],
          "[key name 2]": ["key2 value 1", "key2 value 2"],
      }]
    },
    ..
  ],
  // Specify an amount of an abstract value which can be integers in [1, 2^16]
  // to contribute to each key that is attached to aggregation keys in the
  // order they are generated.
  "aggregatable_values": [
     // Each source event can contribute a maximum of L1 = 2^16 to the
     // aggregate histogram.
    {
     "[key_name]": [value]
    },
    ..
  ],
  aggregatable_deduplication_keys: [{
  deduplication_key": [unsigned 64-bit integer],
    "filters": {
        "category": [filter_1, …, filter_H]
      },
    "not_filters": {
        "category": [filter_1, …, filter_J]
      }
  },
  ...
  {
  "deduplication_key": [unsigned 64-bit integer],
    "filters": {
        "category": [filter_1, …, filter_D]
      },
    "not_filters": {
        "category": [filter_1, …, filter_J]
      }
    }
  ]

  "debug_key": "[64-bit unsigned integer]",
  "debug_reporting": [boolean]

}
// Specify additional ad tech URLs to register this trigger with.
// Repeated Header field "Attribution-Reporting-Redirect"
Attribution-Reporting-Redirect: <Ad Tech Partner URI 1>
Attribution-Reporting-Redirect: <Ad Tech Partner URI 2>

এখানে নমুনা মান যোগ করা একটি উদাহরণ:

Attribution-Reporting-Register-Trigger: {
  "event_trigger_data": [{
    "trigger_data": "1122", // Returns 010 for CTCs and 0 for VTCs in reports.
    "priority": "3",
    "deduplication_key": "3344"
    "filters": [{ // Filter strings can not exceed 25 characters
      "product_id": ["1234"],
      "source_type": ["event"]
    }]
  },
  {
    "trigger_data": "4", // Returns 100 for CTCs and 0 for VTCs in reports.
    "priority": "3",
    "deduplication_key": "3344"
    "filters": [{ // Filter strings can not exceed 25 characters
      "product_id": ["1234"],
      "source_type": ["navigation"]
    }]
  }],
  "aggregatable_trigger_data": [
    // Each dictionary independently adds pieces to multiple source keys.
    {
      // Conversion type purchase = 2 at a 9-bit offset, i.e. 2 << 9.
      // A 9-bit offset is needed because there are 511 possible campaigns,
      // which takes up 9 bits in the resulting key.
      "key_piece": "0x400",// Conversion type purchase = 2
      // Apply this key piece to:
      "source_keys": ["campaignCounts"]
       // Filter strings can not exceed 25 characters
    },
    {
      // Purchase category shirts = 21 at a 7-bit offset, i.e. 21 << 7.
      // A 7-bit offset is needed because there are ~100 regions for the geo
      // key, which takes up 7 bits of space in the resulting key.
      "key_piece": "0xA80",
      // Apply this key piece to:
      "source_keys": ["geoValue", "nonMatchingIdsAreIgnored"]
      // source_key values must not exceed the limit of 25 characters
    }
  ],
  "aggregatable_values":
    {
      // Privacy budget for each key is L1 / 2 = 2^15 (32768).
      // Conversion count was 1.
      // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
      "campaignCounts": 32768,

      // Purchase price was $52.
      // Purchase values for the app range from $1 to $1,024 (integers only).
      // Scaling factor applied is 32768 / 1024 = 32.
      // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
      "geoValue": 1664
    }
  ,
  // aggregatable_deduplication_keys is an optional field. Up to 50 "keys"
  // can be included in the aggregatable_deduplication_keys list. Filters, not
  // filters, and deduplication_key are optional fields. If deduplication_key
  // is omitted, it will be treated as a null value. See
  // https://wicg.github.io/attribution-reporting-api/#triggering-aggregatable-attribution
  aggregatable_deduplication_keys:
  [
    {
    deduplication_key": 3,
        "filters": {
          "category": [A]
        }
    },
    {
    "deduplication_key": 4,
        "filters": {
          "category": [C, D]
        },
        "not_filters": {
          "category": [F]
        }
    }
  ]
  // Opts into receiving verbose debug reports
  "debug_reporting": true
}
Attribution-Reporting-Redirect:https://adtechpartner.example?app_install=567

একত্রিতকরণ কী আইডি এবং ফিল্টার স্ট্রিং প্রতি 25 বাইটের একটি সীমা আছে। এর মানে হল আপনার একত্রিত কী আইডি এবং ফিল্টার স্ট্রিং 25 অক্ষরের বেশি হওয়া উচিত নয়। এই উদাহরণে, campaignCounts 14টি অক্ষর, তাই এটি একটি বৈধ সমষ্টি কী আইডি এবং 1234 4টি অক্ষর, তাই এটি একটি বৈধ ফিল্টার স্ট্রিং৷ যদি একটি সমষ্টি কী আইডি বা ফিল্টার স্ট্রিং 25 অক্ষরের বেশি হয়, ট্রিগার উপেক্ষা করা হয়।

যদি Attribution-Reporting-Redirect বিজ্ঞাপন প্রযুক্তি অংশীদারদের ইউআরআই থাকে, তাহলে অ্যাট্রিবিউশন রিপোর্টিং এপিআই প্রতিটি ইউআরআই-এর জন্য একই রকম অনুরোধ করে। প্রতিটি বিজ্ঞাপন প্রযুক্তি অংশীদারকে অবশ্যই একটি সার্ভার কনফিগার করতে হবে যা এই শিরোনামগুলির সাথে প্রতিক্রিয়া জানায়:

// Metadata associated with trigger.
Attribution-Reporting-Register-Trigger: {
  "event_trigger_data": [{
    // "trigger_data" returned in event reports is truncated to
    // the last 1 or 3 bits, based on conversion type.
    "trigger_data": "[unsigned 64-bit integer]",
    "priority": "[signed 64-bit integer]",
    "deduplication_key": "[signed 64-bit integer]",
    // filter and not_filters are optional fields which allow configuring
    // different event trigger data based on source's filter_data. They
    // consist of a filter set, which is a list of filter maps. An
    // event_trigger_data object is ignored if none of the filter maps in the
    // set match the source's filter data. Note: "source_type" can be used as
    // a key in a filter map to filter based on the source's "navigation" or
    // "event" type. The first Event-Trigger that matches (based on the
    // filters/not_filters) will be used for report generation. If none of the
    // event-triggers match, no report will be generated.
    "filters": [{
      "[key name 1]": ["key1 value 1", "key1 value 2"],
      // If a key is missing from filters or source's filter_data, it will not be
      // used during matching.
      "[key name 2]": ["key2 value 1", "key2 value 2"],
    }],
    "not_filters":  [{
      "[key name 1]": ["key1 value 1", "key1 value 2"],
      // If a key is missing from not_filters or source's filter_data, it will not
      // be used during matching.
      "[key name 2]": ["key2 value 1", "key2 value 2"],
    }]
  }],
  "aggregatable_trigger_data": [
    // Each dictionary entry independently adds pieces to multiple source keys.
    {
      "key_piece": "[key piece value]",
      "source_keys": ["[key name the key piece value applies to]",
      ["list of IDs in source to match. Non-matching IDs are ignored"]],
      // filters/not_filters are optional fields similar to event trigger data
      // filter fields.
      "filters": [{
        "[key name 1]": ["key1 value 1", "key1 value 2"]
      }],
      "not_filters":  [{
          "[key name 1]": ["key1 value 1", "key1 value 2"],
          "[key name 2]": ["key2 value 1", "key2 value 2"],
      }]
    },
    ..
  ],
  // Specify an amount of an abstract value which can be integers in [1, 2^16] to
  // contribute to each key that is attached to aggregation keys in the order they
  // are generated.
  "aggregatable_values": [
    // Each source event can contribute a maximum of L1 = 2^16 to the aggregate
    // histogram.
    {
     "[key_name]": [value]
    }
  ]
}
// The Attribution-Reporting-Redirect header is ignored for ad tech partners.

দ্রষ্টব্য: শুধুমাত্র যে বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্মটি API কল শুরু করে Attribution-Reporting-Redirect এ অংশীদারদের নির্দিষ্ট করতে পারে।

ইভেন্ট-স্তরের রিপোর্ট গ্রহণ করুন

এই শেষ পয়েন্টটি একটি URI থেকে ঠিকানাযোগ্য হওয়া উচিত। ইউআরআই নথিভুক্ত করার বিষয়ে আরও তথ্যের জন্য একটি গোপনীয়তা স্যান্ডবক্স অ্যাকাউন্টের জন্য তালিকাভুক্তি দেখুন। (উৎস নিবন্ধন এবং ট্রিগার নিবন্ধন গ্রহণের জন্য ব্যবহৃত সার্ভারের উত্স থেকে URI অনুমান করা হয়।) উৎস নিবন্ধন গ্রহণ করে এবং ট্রিগার নিবন্ধন গ্রহণ করে এমন এন্ডপয়েন্টগুলির জন্য উদাহরণ URI ব্যবহার করে, এই শেষপয়েন্টের URI হল:

https://adtech.example/.well-known/attribution-reporting/report-event-attribution

নিম্নলিখিত বিন্যাস ব্যবহার করে JSON অনুরোধগুলি গ্রহণ করতে এই সার্ভারটি কনফিগার করুন:

{
  "attribution_destination": "android-app://com.advertiser.example",
  "source_event_id": "12345678",
  "trigger_data": "2",
  "report_id": "12324323",
  "source_type": "navigation",
  "randomized_trigger_rate": "0.02"
   [Optional] "source_debug_key": "[64-bit unsigned integer]",
   [Optional] "trigger_debug_key": "[64-bit unsigned integer]",
}

ডিবাগ কীগুলি আপনার অ্যাট্রিবিউশন রিপোর্টগুলিতে অতিরিক্ত অন্তর্দৃষ্টি দেওয়ার অনুমতি দেয়; তাদের কনফিগার করার বিষয়ে আরও জানুন ।

সমষ্টিগত প্রতিবেদন গ্রহণ করুন

এই শেষ পয়েন্টটি একটি URI থেকে ঠিকানাযোগ্য হওয়া উচিত। ইউআরআই নথিভুক্ত করার বিষয়ে আরও তথ্যের জন্য একটি গোপনীয়তা স্যান্ডবক্স অ্যাকাউন্টের জন্য তালিকাভুক্তি দেখুন। (উৎস নিবন্ধন এবং ট্রিগার নিবন্ধন গ্রহণের জন্য ব্যবহৃত সার্ভারের উত্স থেকে URI অনুমান করা হয়।) উৎস নিবন্ধন গ্রহণ করে এবং ট্রিগার নিবন্ধন গ্রহণ করে এমন এন্ডপয়েন্টগুলির জন্য উদাহরণ URI ব্যবহার করে, এই শেষপয়েন্টের URI হল:

https://adtech.example/.well-known/attribution-reporting/report-aggregate-attribution

দ্রষ্টব্য: এনক্রিপ্ট করা সমষ্টিগত প্রতিবেদন নিজেই বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্মের সরাসরি ব্যবহারের জন্য ডিজাইন করা হয়নি। পরিবর্তে, এটি একত্রীকরণ পরিষেবাগুলির জন্য ইনপুট হিসাবে ব্যবহৃত হয়, যা প্রতিবেদনটি প্রক্রিয়া করে এবং বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্মগুলি ব্যবহার করার জন্য একটি সারাংশ প্রতিবেদন তৈরি করে৷

এনক্রিপ্ট করা এবং এনক্রিপ্ট করা উভয় ক্ষেত্রই সমষ্টিগত প্রতিবেদনের জন্য জনবহুল। এনক্রিপ্ট করা রিপোর্টগুলি আপনাকে একত্রিতকরণ পরিষেবার সাথে পরীক্ষা শুরু করতে সক্ষম করে, যখন এনক্রিপ্ট করা ক্ষেত্রটি কী-মান জোড়াগুলি ডেটা গঠন করার উপায় সম্পর্কে অন্তর্দৃষ্টি প্রদান করে।

নিম্নলিখিত বিন্যাস ব্যবহার করে JSON অনুরোধগুলি গ্রহণ করতে এই সার্ভারটি কনফিগার করুন:

{
  // Info that the aggregation services also need encoded in JSON
  // for use with AEAD. Line breaks added for readability.
  "shared_info": "{
     \"api\":\"attribution-reporting\",
     \"attribution_destination\": \"android-app://com.advertiser.example.advertiser\",
     \"scheduled_report_time\":\"[timestamp in seconds]\",
     \"source_registration_time\": \"[timestamp in seconds]\",
     \"version\":\"[api version]\",
     \"report_id\":\"[UUID]\",
     \"reporting_origin\":\"https://reporter.example\" }",

  // In the current Developer Preview release, The "payload" and "key_id" fields
  // are not used because the platform does not yet encrypt aggregate reports.
  // Currently, the "debug_cleartext_payload" field holds unencrypted reports.
  "aggregation_service_payloads": [
    {
      "payload": "[base64 HPKE encrypted data readable only by the aggregation service]",
      "key_id": "[string identifying public key used to encrypt payload]",

      "debug_cleartext_payload": "[unencrypted payload]"
    },
  ],

  "source_debug_key": "[64 bit unsigned integer]",
  "trigger_debug_key": "[64 bit unsigned integer]"
}

ডিবাগ কীগুলি আপনার অ্যাট্রিবিউশন রিপোর্টগুলিতে অতিরিক্ত অন্তর্দৃষ্টি দেওয়ার অনুমতি দেয়; তাদের কনফিগার করার বিষয়ে আরও জানুন ।

অ্যান্ড্রয়েড ক্লায়েন্ট সেট আপ করুন

ক্লায়েন্ট অ্যাপ অ্যাট্রিবিউশন উত্স এবং ট্রিগার নিবন্ধন করে এবং ইভেন্ট-স্তর এবং সমষ্টিগত প্রতিবেদন তৈরি করতে সক্ষম করে। অ্যাট্রিবিউশন রিপোর্টিং API ব্যবহার করার জন্য একটি অ্যান্ড্রয়েড ক্লায়েন্ট ডিভাইস বা এমুলেটর প্রস্তুত করতে, নিম্নলিখিতগুলি করুন:

1. অ্যান্ড্রয়েডে গোপনীয়তা স্যান্ডবক্সের জন্য আপনার বিকাশের পরিবেশ সেট আপ করুন ৷
2. একটি সমর্থিত ডিভাইসে একটি সিস্টেম ইমেজ ইনস্টল করুন বা Android এ গোপনীয়তা স্যান্ডবক্সের জন্য সমর্থন অন্তর্ভুক্ত করে এমন একটি এমুলেটর সেট আপ করুন ৷

3. নিম্নলিখিত ADB কমান্ডটি চালিয়ে অ্যাট্রিবিউশন রিপোর্টিং API-তে অ্যাক্সেস সক্ষম করুন ৷ (এপিআই ডিফল্টরূপে অক্ষম করা হয়।)

   adb shell device_config put adservices ppapi_app_allow_list \"\*\"

4. আপনি যদি স্থানীয়ভাবে অ্যাট্রিবিউশন রিপোর্টিং এপিআই পরীক্ষা করছেন (যেমন আপনার শারীরিকভাবে অ্যাক্সেস আছে এমন একটি ডিভাইসে পরীক্ষা করা), তালিকা অক্ষম করতে এই কমান্ডটি চালান:

   adb shell device_config put adservices disable_measurement_enrollment_check "true"

5. আপনার Android ম্যানিফেস্ট ফাইলে ACCESS_ADSERVICES_ATTRIBUTION অনুমতি অন্তর্ভুক্ত করুন এবং অ্যাট্রিবিউশন রিপোর্টিং API ব্যবহার করার জন্য আপনার অ্যাপের জন্য একটি বিজ্ঞাপন পরিষেবা কনফিগারেশন তৈরি করুন :

   <uses-permission android:name="android.permission.ACCESS_ADSERVICES_ATTRIBUTION" />
   

6. (ঐচ্ছিক) আপনি যদি ডিবাগ রিপোর্ট পাওয়ার পরিকল্পনা করেন, তাহলে আপনার Android ম্যানিফেস্ট ফাইলে ACCESS_ADSERVICES_AD_ID অনুমতি অন্তর্ভুক্ত করুন:

   <uses-permission android:name="android.permission.ACCESS_ADSERVICES_AD_ID" />
   

7. আপনার ম্যানিফেস্টের <application> অ্যাপ্লিকেশন> উপাদানে একটি বিজ্ঞাপন পরিষেবা কনফিগারেশন উল্লেখ করুন:

   <property android:name="android.adservices.AD_SERVICES_CONFIG"
             android:resource="@xml/ad_services_config" />
   

8. ম্যানিফেস্টে উল্লেখ করা বিজ্ঞাপন পরিষেবাগুলির XML সংস্থানগুলি নির্দিষ্ট করুন, যেমন res/xml/ad_services_config.xml । বিজ্ঞাপন পরিষেবার অনুমতি এবং SDK অ্যাক্সেস নিয়ন্ত্রণ সম্পর্কে আরও জানুন।

   <ad-services-config>
       <attribution allowAllToAccess="true" />
   </ad-services-config>
   

বিজ্ঞাপন ইভেন্ট নিবন্ধন

আপনার অ্যাপের উত্স এবং রূপান্তরগুলি নিবন্ধন করা উচিত যাতে সেগুলি সঠিকভাবে রিপোর্ট করা হয় তা নিশ্চিত করতে। MeasurementManager ক্লাস পদ্ধতিগুলি আপনাকে অ্যাট্রিবিউশন সোর্স ইভেন্ট এবং রূপান্তর ট্রিগার নিবন্ধন করতে সহায়তা করে।

একটি অ্যাট্রিবিউশন সোর্স ইভেন্ট নিবন্ধন করুন

যখন একটি বিজ্ঞাপন দেখা বা ক্লিক করা হয়, তখন একটি প্রকাশক অ্যাপ কোড স্নিপেটে দেখানো হিসাবে একটি অ্যাট্রিবিউশন উত্স নিবন্ধন করতে registerSource() কল করে৷

অ্যাট্রিবিউশন রিপোর্টিং API নিম্নলিখিত ধরনের অ্যাট্রিবিউশন সোর্স ইভেন্ট সমর্থন করে:

• ক্লিকগুলি, যা আপনি সাধারণত onClick() এর অনুরূপ একটি কলব্যাক পদ্ধতির মধ্যে নিবন্ধন করেন। সংশ্লিষ্ট ট্রিগার ইভেন্টটি সাধারণত ক্লিক ইভেন্টের পরেই ঘটে। এই ধরনের ইভেন্ট ব্যবহারকারীর মিথস্ক্রিয়া সম্পর্কে আরও তথ্য প্রদান করে এবং তাই উচ্চ অগ্রাধিকার দেওয়ার জন্য এটি একটি ভাল ধরনের অ্যাট্রিবিউশন উত্স।

• ভিউ, যা আপনি সাধারণত onAdShown() এর মতো কলব্যাক পদ্ধতিতে নিবন্ধন করেন। সংশ্লিষ্ট ট্রিগার ইভেন্টটি দেখার ইভেন্টের কয়েক ঘন্টা বা দিন পরে ঘটতে পারে।

কোটলিন

companion object {
    private val CALLBACK_EXECUTOR = Executors.newCachedThreadPool()
}

val measurementManager = context.getSystemService(MeasurementManager::class.java)
var exampleClickEvent: InputEvent? = null

// Use the URI of the server-side endpoint that accepts attribution source
// registration.
val attributionSourceUri: Uri =
  Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA")

val future = CompletableFuture<Void>()

adView.setOnTouchListener(_: View?, event: MotionEvent?)) ->
    exampleClickEvent = event
    true
}

// Register Click Event
measurementManager.registerSource(
        attributionSourceUri,
        exampleClickEvent,
        CALLBACK_EXECUTOR,
        future::complete)

// Register View Event
measurementManager.registerSource(
        attributionSourceUri,
        null,
        CALLBACK_EXECUTOR,
        future::complete)

জাভা

private static final Executor CALLBACK_EXECUTOR = Executors.newCachedThreadPool();
private InputEvent exampleClickEvent;

MeasurementManager measurementManager =
        context.getSystemService(MeasurementManager.class);

// Use the URI of the server-side endpoint that accepts attribution source
// registration.
Uri attributionSourceUri =
Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA");

CompletableFuture<Void> future = new CompletableFuture<>();

adView.setOnTouchListener(v, event)) -> {
    exampleClickEvent = event;
    return true;
}

// Register Click Event
measurementManager.registerSource(attributionSourceUri, exampleClickEvent,
        CALLBACK_EXECUTOR, future::complete);

// Register View Event
measurementManager.registerSource(attributionSourceUri, null,
        CALLBACK_EXECUTOR, future::complete);

রেজিস্ট্রেশনের পরে, API attributionSourceUri দ্বারা নির্দিষ্ট ঠিকানায় পরিষেবার শেষ পয়েন্টে একটি HTTP POST অনুরোধ জারি করে। এন্ডপয়েন্টের প্রতিক্রিয়াতে destination, source_event_id, expiry , এবং source_priority এর মান রয়েছে।

যদি উদ্ভূত বিজ্ঞাপন প্রযুক্তি উৎস নিবন্ধন শেয়ার করতে চায়, তাহলে মূল অ্যাট্রিবিউশন উৎস URI-তে অন্যান্য বিজ্ঞাপন প্রযুক্তির শেষ পয়েন্টে রিডাইরেক্ট অন্তর্ভুক্ত থাকতে পারে। পুনঃনির্দেশের ক্ষেত্রে প্রযোজ্য সীমা এবং নিয়মগুলি প্রযুক্তিগত প্রস্তাবে বিশদভাবে উল্লেখ করা হয়েছে।

registerSource এবং registerTrigger এর জন্য ডেইজি-চেইন পুনঃনির্দেশের জন্য সমর্থন যোগ করা হয়েছে। নিবন্ধন শিরোনাম ছাড়াও, এপিআই গ্রাহক এখন সার্ভার প্রতিক্রিয়া হিসাবে একটি HTTP পুনঃনির্দেশ প্রদান করতে পারে যাতে একটি 302 স্ট্যাটাস কোড এবং একটি "অবস্থান" শিরোনাম থাকে যা পরবর্তী URL সহ একটি অতিরিক্ত নিবন্ধনের জন্য পরিদর্শন করতে পারে৷

শুধুমাত্র প্রথম দর্শনে দেওয়া "গন্তব্য" ক্ষেত্রটি ডেইজি-চেইন জুড়ে ব্যবহৃত হয়। "অ্যাট্রিবিউশন-রিপোর্টিং-রিডাইরেক্ট" শিরোনামগুলির মতোই ভিজিটের সংখ্যার সীমা রয়েছে৷ এই পুনঃনির্দেশ সমর্থন বিদ্যমান "অ্যাট্রিবিউশন-রিপোর্টিং-পুনঃনির্দেশ" সমর্থন ছাড়াও, এবং উভয়ই উপস্থিত থাকলে, "অ্যাট্রিবিউশন-রিপোর্টিং-পুনঃনির্দেশ" অগ্রাধিকার পায়।

একটি রূপান্তর ট্রিগার ইভেন্ট নিবন্ধন

একটি রূপান্তর ট্রিগার ইভেন্ট নিবন্ধন করতে, আপনার অ্যাপে registerTrigger() কল করুন:

কোটলিন

companion object {
    private val CALLBACK_EXECUTOR = Executors.newCachedThreadPool()
}

val measurementManager = context.getSystemService(MeasurementManager::class.java)

// Use the URI of the server-side endpoint that accepts trigger registration.
val attributionTriggerUri: Uri =
    Uri.parse("https://adtech.example/trigger?AD_TECH_PROVIDED_METADATA")

val future = CompletableFuture<Void>()

// Register trigger (conversion)
measurementManager.registerTrigger(
        attributionTriggerUri,
        CALLBACK_EXECUTOR,
        future::complete)

জাভা

private static final Executor CALLBACK_EXECUTOR = Executors.newCachedThreadPool();

MeasurementManager measurementManager =
        context.getSystemService(MeasurementManager.class);

// Use the URI of the server-side endpoint that accepts trigger registration.
Uri attributionTriggerUri =
        Uri.parse("https://adtech.example/trigger?AD_TECH_PROVIDED_METADATA");

CompletableFuture<Void> future = new CompletableFuture<>();

// Register trigger (conversion)
measurementManager.registerTrigger(
        attributionTriggerUri,
        CALLBACK_EXECUTOR,
        future::complete)

রেজিস্ট্রেশনের পর, API attributionTriggerUri দ্বারা নির্দিষ্ট ঠিকানায় পরিষেবার শেষ পয়েন্টে একটি HTTP POST অনুরোধ জারি করে। শেষবিন্দুর প্রতিক্রিয়া ইভেন্ট এবং সমষ্টিগত প্রতিবেদনের মান অন্তর্ভুক্ত করে।

যদি উদ্ভূত বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্ম ট্রিগার নিবন্ধন শেয়ার করার অনুমতি দেয়, তাহলে URI অন্যান্য বিজ্ঞাপন প্রযুক্তি প্ল্যাটফর্মের অন্তর্গত URI-তে রিডাইরেক্ট অন্তর্ভুক্ত করতে পারে। পুনঃনির্দেশের ক্ষেত্রে প্রযোজ্য সীমা এবং নিয়মগুলি প্রযুক্তিগত প্রস্তাবে বিশদভাবে উল্লেখ করা হয়েছে।

ক্রস অ্যাপ এবং ওয়েব পরিমাপ নিবন্ধন করুন

যে ক্ষেত্রে একটি অ্যাপ এবং ব্রাউজার উভয়ই উৎস থেকে ট্রিগারে ব্যবহারকারীর যাত্রায় ভূমিকা পালন করে , সেখানে বিজ্ঞাপন ইভেন্ট নিবন্ধন করার ক্ষেত্রে সূক্ষ্ম পার্থক্য রয়েছে। যদি একজন ব্যবহারকারী একটি অ্যাপে একটি বিজ্ঞাপন দেখে এবং একটি রূপান্তরের জন্য একটি ব্রাউজারে পুনঃনির্দেশিত হয়, তাহলে উৎসটি অ্যাপের দ্বারা নিবন্ধিত হয় এবং ওয়েব ব্রাউজার দ্বারা রূপান্তর করা হয়৷ একইভাবে, যদি একজন ব্যবহারকারী একটি ওয়েব ব্রাউজারে শুরু করে এবং রূপান্তরের জন্য একটি অ্যাপে নির্দেশিত হয়, ব্রাউজার উৎসটি নিবন্ধন করে এবং অ্যাপটি রূপান্তর নিবন্ধন করে।

যেহেতু ওয়েবে এবং অ্যান্ড্রয়েডে বিজ্ঞাপন প্রযুক্তি সংগঠিত করা হয় তার মধ্যে পার্থক্য রয়েছে, তাই আমরা নতুন API যোগ করেছি উৎস নিবন্ধন করার জন্য এবং ট্রিগারগুলি যখন ব্রাউজারে হয়। এই API এবং সংশ্লিষ্ট অ্যাপ-ভিত্তিক APIগুলির মধ্যে মূল পার্থক্য হল যে আমরা আশা করি যে ব্রাউজারটি পুনঃনির্দেশগুলি অনুসরণ করবে, যে কোনও ব্রাউজার-নির্দিষ্ট ফিল্টার প্রয়োগ করবে এবং registerWebSource() বা registerWebTrigger() কল করে প্ল্যাটফর্মে বৈধ নিবন্ধনগুলি পাস করবে।

নিম্নলিখিত কোড স্নিপেটটি API কলের একটি উদাহরণ দেখায় যা ব্রাউজার একটি অ্যাপে ব্যবহারকারীকে নির্দেশ করার আগে একটি অ্যাট্রিবিউশন উত্স নিবন্ধন করতে করে:

কোটলিন

companion object {
    private val CALLBACK_EXECUTOR = Executors.newCachedThreadPool()
}

val measurementManager =
        context.getSystemService(MeasurementManager::class.java)
var exampleClickEvent: InputEvent? = null

// Use the URIs of the server-side endpoints that accept attribution source
// registration.
val sourceParam1 = WebSourceParams.Builder(Uri.parse(
        "https://adtech1.example/attribution_source?AD_TECH_PROVIDED_METADATA"))
// True, if debugging is allowed for the ad tech.
    .setDebugKeyAllowed(true)
    .build()

val sourceParam2 = WebSourceParams.Builder(Uri.parse(
        "https://adtech2.example/attribution_source?AD_TECH_PROVIDED_METADATA"))
    .setDebugKeyAllowed(false)
    .build()

val sourceParam3 = WebSourceParams.Builder(Uri.parse(
        "https://adtech3.example/attribution_source?AD_TECH_PROVIDED_METADATA"))
    .build()

val sourceParams = Arrays.asList(sourceParam1, sourceParam2, sourceParam3)
val publisherOrigin = Uri.parse("https://publisher.example")
val appDestination = Uri.parse("android-app://com.example.store")
val webDestination = Uri.parse("https://example.com")

val future = CompletableFuture<Void>()

adView.setOnTouchListener {_: View?, event: MotionEvent? ->
    exampleClickEvent = event
    true
}
val clickRegistrationRequest = WebSourceRegistrationRequest.Builder(
          sourceParams,
          publisherOrigin)
      .setAppDestination(appDestination)
      .setWebDestination(webDestination)
      .setInputEvent(event)
      .build()
val viewRegistrationRequest = WebSourceRegistrationRequest.Builder(
          sourceParams,
          publisherOrigin)
      .setAppDestination(appDestination)
      .setWebDestination(webDestination)
      .setInputEvent(null)
      .build()

// Register a web source for a click event.
measurementManager.registerWebSource(
        clickRegistrationRequest,
        CALLBACK_EXECUTOR,
        future::complete)

// Register a web source for a view event.
measurementManager.registerWebSource(
        viewRegistrationRequest,
        CALLBACK_EXECUTOR,
        future::complete)

জাভা

private static final Executor CALLBACK_EXECUTOR =
        Executors.newCachedThreadPool();
private InputEvent exampleClickEvent;

MeasurementManager measurementManager =
        context.getSystemService(MeasurementManager.class);

// Use the URIs of the server-side endpoints that accept attribution source
// registration.
WebSourceParams sourceParam1 = WebSourceParams.Builder(Uri.parse(
        "https://adtech1.example/attribution_source?AD_TECH_PROVIDED_METADATA"))
    // True, if debugging is allowed for the ad tech.
    .setDebugKeyAllowed(true)
    .build();

WebSourceParams sourceParam2 = WebSourceParams.Builder(Uri.parse(
        "https://adtech2.example/attribution_source?AD_TECH_PROVIDED_METADATA"))
    .setDebugKeyAllowed(false)
    .build();

WebSourceParams sourceParam3 = WebSourceParams.Builder(Uri.parse(
        "https://adtech3.example/attribution_source?AD_TECH_PROVIDED_METADATA"))
    .build();

List<WebSourceParams> sourceParams =
        Arrays.asList(sourceParam1, sourceParam2, sourceParam3);
Uri publisherOrigin = Uri.parse("https://publisher.example");
Uri appDestination = Uri.parse("android-app://com.example.store");
Uri webDestination = Uri.parse("https://example.com");

CompletableFuture<Void> future = new CompletableFuture<>();

adView.setOnTouchListener(v, event) -> {
    exampleClickEvent = event;
    return true;
}

WebSourceRegistrationRequest clickRegistrationRequest =
        new WebSourceRegistrationRequest.Builder(sourceParams, publisherOrigin)
    .setAppDestination(appDestination)
    .setWebDestination(webDestination)
    .setInputEvent(event)
    .build();
WebSourceRegistrationRequest viewRegistrationRequest =
        new WebSourceRegistrationRequest.Builder(sourceParams, publisherOrigin)
    .setAppDestination(appDestination)
    .setWebDestination(webDestination)
    .setInputEvent(null)
    .build();

// Register a web source for a click event.
measurementManager.registerWebSource(clickRegistrationRequest,
        CALLBACK_EXECUTOR, future::complete);

// Register a web source for a view event.
measurementManager.registerWebSource(viewRegistrationRequest,
        CALLBACK_EXECUTOR, future::complete);

নিম্নলিখিত কোড স্নিপেটটি API কলের একটি উদাহরণ দেখায় যা ব্রাউজার অ্যাপ থেকে নির্দেশিত হওয়ার পরে একটি রূপান্তর নিবন্ধন করতে করে:

কোটলিন

companion object {
    private val CALLBACK_EXECUTOR = Executors.newCachedThreadPool()
}

val measurementManager = context.getSystemService(MeasurementManager::class.java)

// Use the URIs of the server-side endpoints that accept trigger registration.
val triggerParam1 = WebTriggerParams.Builder(Uri.parse(
        "https://adtech1.example/trigger?AD_TECH_PROVIDED_METADATA"))
    // True, if debugging is allowed for the ad tech.
    .setDebugKeyAllowed(true)
    .build()

val triggerParam2 = WebTriggerParams.Builder(Uri.parse(
        "https://adtech2.example/trigger?AD_TECH_PROVIDED_METADATA"))
    .setDebugKeyAllowed(false)
    .build()

val triggerParams = Arrays.asList(triggerParam1, triggerParam2)
val advertiserOrigin = Uri.parse("https://advertiser.example")

val future = CompletableFuture<Void>()

val triggerRegistrationRequest = WebTriggerRegistrationRequest.Builder(
        triggerParams,
        advertiserOrigin)
    .build()

// Register the web trigger (conversion).
measurementManager.registerWebTrigger(
    triggerRegistrationRequest,
    CALLBACK_EXECUTOR,
    future::complete)

জাভা

private static final Executor CALLBACK_EXECUTOR =
        Executors.newCachedThreadPool();

MeasurementManager measurementManager =
        context.getSystemService(MeasurementManager.class);

// Use the URIs of the server-side endpoints that accept trigger registration.
WebTriggerParams triggerParam1 = WebTriggerParams.Builder(Uri.parse(
        "https://adtech1.example/trigger?AD_TECH_PROVIDED_METADATA"))
    // True, if debugging is allowed for the ad tech.
    .setDebugKeyAllowed(true)
    .build();

WebTriggerParams triggerParam2 = WebTriggerParams.Builder(Uri.parse(
        "https://adtech2.example/trigger?AD_TECH_PROVIDED_METADATA"))
    .setDebugKeyAllowed(false)
    .build();

List<WebTriggerParams> triggerParams =
        Arrays.asList(triggerParam1, triggerParam2);
Uri advertiserOrigin = Uri.parse("https://advertiser.example");

CompletableFuture<Void> future = new CompletableFuture<>();

WebTriggerRegistrationRequest triggerRegistrationRequest =
        new WebTriggerRegistrationRequest.Builder(
            triggerParams, advertiserOrigin)
    .build();

// Register the web trigger (conversion).
measurementManager.registerWebTrigger( triggerRegistrationRequest,
        CALLBACK_EXECUTOR, future::complete);

গোপনীয়তার জন্য শোরগোল যোগ করা হচ্ছে

ইভেন্ট-লেভেল রিপোর্টে গন্তব্য, অ্যাট্রিবিউশন সোর্স আইডি এবং ট্রিগার ডেটা থাকে। এগুলি রিপোর্টিং মূলে আসল (এনক্রিপ্ট করা) বিন্যাসে পাঠানো হয়। ব্যবহারকারীর গোপনীয়তা রক্ষা করার জন্য, স্বতন্ত্র ব্যবহারকারীকে সনাক্ত করা আরও কঠিন করার জন্য শব্দ যোগ করা যেতে পারে। নয়েজড ইভেন্ট-লেভেল রিপোর্ট তৈরি করা হয় এবং ডিফারেনশিয়াল-প্রাইভেসি ফ্রেমওয়ার্ক অনুযায়ী পাঠানো হয়। এইগুলি বিভিন্ন পরিস্থিতিতে ডিফল্ট শব্দ শতাংশ মান:

উত্স প্রকার	উৎস গন্তব্য মান	সোর্স রেজিস্ট্রেশন প্রতি গোলমাল রিপোর্ট সম্ভাবনা
দেখুন	হয় অ্যাপ বা ওয়েব	0.0000025
দেখুন	অ্যাপ এবং ওয়েব	0.0000042
ক্লিক করুন	হয় অ্যাপ বা ওয়েব	0.0024263
ক্লিক করুন	অ্যাপ এবং ওয়েব	0.0170218

অ্যাপ-টু-ওয়েব অ্যাট্রিবিউশন পরিমাপে, যেখানে উত্সগুলি অ্যাপ এবং ওয়েব উভয় গন্তব্যে রূপান্তর চালাতে পারে, ইভেন্ট-স্তরের রিপোর্টগুলি অ্যাপ বা ওয়েবে ট্রিগার ঘটেছে কিনা তা নির্দিষ্ট করতে পারে। এই অতিরিক্ত বিশদ বিবরণের জন্য ক্ষতিপূরণ দিতে, উত্পন্ন নয়েজড রিপোর্টগুলি ক্লিকের জন্য ~7x এবং দর্শনের জন্য ~1.7x পর্যন্ত।

অ্যাপ বা ওয়েব গন্তব্যে ট্রিগার ঘটেছে কিনা তা নির্দিষ্ট করার জন্য কিছু বিজ্ঞাপন প্রযুক্তির ইভেন্ট-লেভেল রিপোর্টের প্রয়োজন হয় না। বিজ্ঞাপন প্রযুক্তিগুলি আওয়াজ কমাতে Attribution-Reporting-Register-Source হেডারের অধীনে coarse_event_report_destinations ক্ষেত্র ব্যবহার করতে পারে। যদি coarse_event_report_destinations ক্ষেত্রে নির্দিষ্ট করা কোনো উৎস অ্যাট্রিবিউশন জয় করে, তাহলে প্রকৃত ট্রিগারটি কোথায় ঘটেছে তার কোনো পার্থক্য ছাড়াই রিপোর্টে অ্যাপ এবং ওয়েব গন্তব্য উভয়ই অন্তর্ভুক্ত থাকে।

নিম্নলিখিত উদাহরণগুলিতে, একজন ব্যবহারকারী একটি বিজ্ঞাপনে ক্লিক করেন এবং সেই উত্সটি API-এর সাথে নিবন্ধিত হয়৷ ব্যবহারকারী তারপর বিজ্ঞাপনদাতা অ্যাপ এবং বিজ্ঞাপনদাতার ওয়েবসাইট উভয়েই রূপান্তর করে। এই উভয় রূপান্তরই ট্রিগার হিসাবে নিবন্ধিত এবং প্রাথমিক ক্লিকের জন্য দায়ী।

একটি ক্লিক-ভিত্তিক উৎস নিবন্ধন HTTP শিরোনাম:

Attribution-Reporting-Register-Source: {
    "destination": "android-app://com.advertiser.example",
    "web_destination": "https://advertiser.com",
    "source_event_id": "234",
    "expiry": "60000",
    "priority": "5",
    // Ad tech opts out of receiving app-web destination distinction
    // in event report, avoids additional noise
    "coarse_event_report_destinations": "true"
}

com.advertiser.example প্যাকেজ নাম দিয়ে অ্যাপ থেকে একটি ট্রিগার নিবন্ধিত হয়েছে:

Attribution-Reporting-Register-Trigger: {
    "event_trigger_data": [{
    "trigger_data": "1",
    "priority": "1"
    }],
}

eTLD+1 ডোমেন https://advertiser.com সহ ওয়েবসাইট থেকে একটি ব্রাউজার থেকে একটি ট্রিগার নিবন্ধিত হয়:

Attribution-Reporting-Register-Trigger: {
    "event_trigger_data": [{
    "trigger_data": "2",
    "priority": "2"
    }],
}

ফলস্বরূপ ইভেন্ট-স্তরের রিপোর্ট তৈরি করা হয়। উভয় ট্রিগার উত্সের জন্য দায়ী করা হয়েছে বলে ধরে নিলে, নিম্নলিখিত ইভেন্ট-স্তরের প্রতিবেদন তৈরি করা হয়:

  {
    "attribution_destination": ["android-app://com.advertiser.example,https://advertiser.com"],
    "scheduled_report_time": "800176400",
    "source_event_id": "53234",
    "trigger_data": "1",
    // Can be "event" if source were registered by user viewing the ad
    "source_type": "navigation",
    // Would be 0.0170218 without coarse_event_report_destinations as true in the source
    "randomized_trigger_rate": 0.0024263
  }

রিপোর্ট তৈরি এবং বিতরণ

অ্যাট্রিবিউশন রিপোর্টিং API আপনার সার্ভারের শেষ পয়েন্টগুলিতে রিপোর্ট পাঠায় যা ইভেন্ট-স্তরের রিপোর্ট এবং সমষ্টিগত রিপোর্টগুলি গ্রহণ করে।

রিপোর্টিং কাজ চালানোর জন্য বল করুন

আপনি একটি অ্যাট্রিবিউশন সোর্স ইভেন্ট নিবন্ধন করার পরে বা একটি ট্রিগার ইভেন্ট নিবন্ধন করার পরে, সিস্টেমটি চালানোর জন্য রিপোর্টিং কাজের সময় নির্ধারণ করে। ডিফল্টরূপে, এই কাজটি প্রতি 4 ঘন্টা চলে। পরীক্ষার উদ্দেশ্যে, আপনি রিপোর্টিং কাজগুলি চালানোর জন্য বাধ্য করতে পারেন বা কাজের মধ্যে ব্যবধান ছোট করতে পারেন।

জোর করে অ্যাট্রিবিউশন কাজ চালাতে:

adb shell cmd jobscheduler run -f com.google.android.adservices.api 5

ইভেন্ট-লেভেল রিপোর্টিং কাজ চালাতে বাধ্য করুন:

adb shell cmd jobscheduler run -f com.google.android.adservices.api 3

সমষ্টিগত রিপোর্টিং কাজ চালাতে বাধ্য করুন:

adb shell cmd jobscheduler run -f com.google.android.adservices.api 7

কাজগুলি কখন চালানো হয়েছে তা দেখতে লগক্যাটে আউটপুট পরীক্ষা করুন৷ এটি নিম্নলিখিত মত কিছু দেখতে হবে:

JobScheduler: executeRunCommand(): com.google.android.adservices.api/0 5 s=false f=true

রিপোর্ট প্রদান জোর করে

এমনকি রিপোর্টিং কাজ চালানোর জন্য বাধ্য করা হলেও, সিস্টেম এখনও তাদের নির্ধারিত ডেলিভারির সময় অনুযায়ী রিপোর্ট পাঠায়, যা কয়েক ঘন্টা থেকে কয়েক দিন পর্যন্ত। পরীক্ষার উদ্দেশ্যে, আপনি রিপোর্ট ডেলিভারি শুরু করার জন্য নির্ধারিত বিলম্বের পরে ডিভাইস সিস্টেমের সময়কে এগিয়ে নিতে পারেন।

আপনার সার্ভারে রিপোর্ট যাচাই করুন

একবার রিপোর্ট পাঠানো হলে, প্রাপ্ত রিপোর্ট, প্রযোজ্য সার্ভার লগ যেমন মক সার্ভার ইতিহাস বা আপনার কাস্টম সিস্টেম চেক করে ডেলিভারি যাচাই করুন।

আপনার সমষ্টিগত প্রতিবেদন ডিকোড করুন

একটি সমষ্টিগত প্রতিবেদন পাওয়ার সময়, debug_cleartext_payload ক্ষেত্রটি আপনার সমষ্টিগত প্রতিবেদনের একটি এনক্রিপ্ট করা সংস্করণ ধারণ করে। যদিও আপনার প্রতিবেদনের এই সংস্করণটি এনক্রিপ্ট করা হয়নি, তবুও এটিকে ডিকোড করা প্রয়োজন৷

নিচে debug_cleartext_payload ক্ষেত্রের বিষয়বস্তু দুটি ধাপে ডিকোড করার একটি উদাহরণ: প্রথমটি বেস 64 ডিকোডিং ব্যবহার করে এবং দ্বিতীয়টি CBOR ডিকোডিং ব্যবহার করে।

String base64DebugPayload  = "omRkYXRhgqJldmFsdWVEAAAGgGZidWNrZXRQAAAAAAAAAAAAAAAAAAAKhaJldmFsdWVEAACAAGZidWNrZXRQAAAAAAAAAAAAAAAAAAAFWWlvcGVyYXRpb25paGlzdG9ncmFt";
byte[] cborEncoded = Base64.getDecoder().decode(base64DebugPayload);

// CbodDecoder comes from this library https://github.com/c-rack/cbor-java
final List<DataItem> dataItems = new CborDecoder(new ByteArrayInputStream(cborEncoded)).decode();

// In here you can see the contents, but the value will be something like:
// Data items: [{ data: [{ value: co.nstant.in.cbor.model.ByteString@a8b5c07a,
//   bucket: co.nstant.in.cbor.model.ByteString@f812097d },
//   { value: co.nstant.in.cbor.model.ByteString@a8b5dfc0,
//   bucket: co.nstant.in.cbor.model.ByteString@f8120934 }], operation: histogram }]
Log.d("Data items : " + dataItems);

// In order to see the value for bucket and value, you can traverse the data
// and get their values, something like this:
final Map payload = (Map) dataItems.get(0);
final Array payloadArray = (Array) payload.get(new UnicodeString("data"));

payloadArray.getDataItems().forEach(i -> {
    BigInteger value = new BigInteger(((ByteString) ((Map)i).get(new UnicodeString("value"))).getBytes());
    BigInteger bucket = new BigInteger(((ByteString) ((Map)i).get(new UnicodeString("bucket"))).getBytes());
    Log.d("value : " + value + " ;bucket : " + bucket);
});

টেস্টিং

আপনাকে অ্যাট্রিবিউশন রিপোর্টিং API দিয়ে শুরু করতে সাহায্য করার জন্য, আপনি GitHub-এ MeasurementSampleApp প্রকল্প ব্যবহার করতে পারেন। এই নমুনা অ্যাপটি অ্যাট্রিবিউশন সোর্স রেজিস্ট্রেশন এবং ট্রিগার রেজিস্ট্রেশন দেখায়।

সার্ভার এন্ডপয়েন্টের জন্য, নিম্নলিখিত রেফারেন্স রিসোর্স বা আপনার কাস্টম সমাধান বিবেচনা করুন:

• MeasurementAdTechServerSpec-এ OpenAPI পরিষেবার সংজ্ঞা রয়েছে, যা একটি সমর্থিত মক বা মাইক্রোসার্ভিসেস প্ল্যাটফর্মে স্থাপন করা যেতে পারে।
• MeasurementAdTechServer Google App Engine-এর জন্য Spring Boot অ্যাপের উপর ভিত্তি করে একটি মক সার্ভারের একটি রেফারেন্স বাস্তবায়ন অন্তর্ভুক্ত করে।

পূর্বশর্ত

আপনার পরীক্ষা ডিভাইস বা এমুলেটর থেকে অ্যাক্সেসযোগ্য দূরবর্তী শেষ পয়েন্টগুলিতে মক API গুলি স্থাপন করুন৷ পরীক্ষার সহজতার জন্য, MeasurementAdTechServerSpec এবং MeasurementAdTechServer নমুনা প্রকল্পগুলি পড়ুন।

পরীক্ষা করার জন্য কার্যকারিতা

• অ্যাট্রিবিউশন উত্স এবং রূপান্তর ট্রিগার নিবন্ধন অনুশীলন করুন। সার্ভার-সাইড এন্ডপয়েন্ট সঠিক বিন্যাসের সাথে সাড়া দিচ্ছে কিনা তা পরীক্ষা করুন।
• রিপোর্টিং কাজ চালানো.
• আপনার পরীক্ষার সার্ভারের ব্যাকএন্ড বা কনসোলে রিপোর্টের ডেলিভারি যাচাই করুন ।

আসন্ন বৈশিষ্ট্য

নমনীয় ইভেন্ট-স্তরের কনফিগারেশন

ইভেন্ট লেভেল রিপোর্টিংয়ের জন্য ডিফল্ট কনফিগারেশনটি ইউটিলিটি টেস্টিং শুরু করার পরামর্শ দেওয়া হয়, কিন্তু সব ব্যবহারের ক্ষেত্রে এটি আদর্শ নাও হতে পারে। অ্যাট্রিবিউশন রিপোর্টিং API ঐচ্ছিক, আরও নমনীয় কনফিগারেশনকে সমর্থন করবে যাতে বিজ্ঞাপন প্রযুক্তিগুলি তাদের ইভেন্ট স্তরের প্রতিবেদনের কাঠামোর উপর নিয়ন্ত্রণ বাড়িয়েছে এবং ডেটার উপযোগিতাকে সর্বাধিক করতে সক্ষম হয়৷ এই অতিরিক্ত নমনীয়তা দুটি ধাপে অ্যাট্রিবিউশন রিপোর্টিং API-তে প্রবর্তন করা হবে:

• ফেজ 1 : লাইট নমনীয় ইভেন্ট লেভেল কনফিগারেশন; ফেজ 2 এর একটি উপসেট।
• পর্যায় 2 : নমনীয় ইভেন্ট লেভেল কনফিগারেশনের সম্পূর্ণ সংস্করণ।

পর্যায় 1: হালকা নমনীয় ইভেন্ট স্তর

আমরা Attribution-Reporting-Register-Source এ JSON-এ নিম্নলিখিত দুটি ঐচ্ছিক প্যারামিটার যোগ করব:

• max_event_level_reports
• event_report_windows

{
  ...
  // Optional. This is a parameter that acts across all trigger types for the
  // lifetime of this source. It restricts the total number of event-level
  // reports that this source can generate. After this maximum is hit, the
  // source is no longer capable of producing any new data. The use of
  // priority in the trigger attribution algorithm in the case of multiple
  // attributable triggers remains unchanged. Defaults to 3 for navigation
  // sources and 1 for event sources
  "max_event_level_reports": <int>,

  // Optional. Represents a series of time windows, starting at 0. Reports
  // for this source will be delivered an hour after the end of each window.
  // Time is encoded as seconds after source registration. If
  // event_report_windows is omitted, will use the default windows. This
  // field is mutually exclusive with the existing `event_report_window` field.
  // // End time is exclusive.
  "event_report_windows": {
    "start_time": <int>,
    "end_times": [<int>, ...]
  }
}

দ্রষ্টব্য: event_report_window এবং event_report_windows উভয়ই উপস্থিত থাকলে উৎসটি উপেক্ষা করা হয়। সোর্স রেজিস্ট্রেশনে এর মধ্যে শুধুমাত্র একটি উপস্থিত থাকতে পারে।

কাস্টম কনফিগারেশন উদাহরণ

এই উদাহরণ কনফিগারেশনটি এমন একজন ডেভেলপারকে সমর্থন করে যে পূর্বের রিপোর্টিং উইন্ডোতে রিপোর্ট পাওয়ার জন্য অপ্টিমাইজ করতে চায়।

{
  ...
  "max_event_level_reports": 2,
  "event_report_windows": {
    "end_times": [7200, 43200, 86400] // 2 hours, 12 hours, 1 day in seconds
  }
}

পর্যায় 2: সম্পূর্ণ নমনীয় ইভেন্ট স্তর

পর্যায় 1-এ যোগ করা প্যারামিটারগুলি ছাড়াও, আমরা Attribution-Reporting-Register-Source এ JSON-এ একটি অতিরিক্ত ঐচ্ছিক প্যারামিটার trigger_specs যোগ করব।

{
  // A trigger spec is a set of matching criteria, along with a scheme to
  // generate bucketized output based on accumulated values across multiple
  // triggers within the specified event_report_window. There will be a limit on
  // the number of specs possible to define for a source.
  "trigger_specs": [{
    // This spec will only apply to registrations that set one of the given
    // trigger data values (non-negative integers) in the list.
    // trigger_data will still appear in the event-level report.
    "trigger_data": [<int>, ...]

    // Represents a series of time windows, starting at the source registration
    // time. Reports for this spec will be delivered an hour after the end of
    // each window. Time is encoded as seconds after source registration.
    // end_times must consist of strictly increasing positive integers.
    //
    // Note: specs with identical trigger_data cannot have overlapping windows;
    // this ensures that triggers match at most one spec. If
    // event_report_windows is omitted, will use the "event_report_window" or
    // "event_report_windows" field specified at the global level for the source
    // (or the default windows if none are specified). End time is exclusive.
    "event_report_windows": {
      "start_time": <int>,
      "end_times": [<int>, ...],
    }

    // Represents an operator that summarizes the triggers within a window
    // count: number of triggers attributed within a window
    // value_sum: sum of the value of triggers within a window
    // The summary is reported as an index into a bucketization scheme. Defaults
    // to "count"
    "summary_window_operator": <one of "count" or "value_sum">,

    // Represents a bucketization of the integers from [0, MAX_INT], encoded as
    // a list of integers where new buckets begin (excluding 0 which is
    // implicitly included).
    // It must consist of strictly increasing positive integers.
    //
    // e.g. [5, 10, 100] encodes the following ranges:
    // [[0, 4], [5, 9], [10, 99], [100, MAX_INT]]
    //
    // At the end of each reporting window, triggers will be summarized into an
    // integer which slots into one of these ranges. Reports will be sent for
    // every new range boundary that is crossed. Reports will never be sent for
    // the range that includes 0, as every source is initialized in this range.
    //
    // If omitted, then represents a trivial mapping
    // [1, 2, ... , MAX_INT]
    // With MAX_INT being the maximum int value defined by the browser.
    "summary_buckets": [<bucket start>, ...]
  }, {
    // Next trigger_spec
  } ...],

  // See description in phase 1.
  "max_event_level_reports": <int>
  // See description in phase 1.
  "event_report_windows": {
    "start_time": <int>,
    "end_times": [<int>, ...]
  }
}

এই কনফিগারেশনটি উৎস রেজিস্ট্রেশন প্রতি ইভেন্ট-স্তরের রিপোর্টের আউটপুট স্থান সম্পূর্ণরূপে নির্দিষ্ট করে। প্রতিটি ট্রিগার স্পেকের জন্য, আমরা সম্পূর্ণভাবে উল্লেখ করি:

• মানদণ্ডের একটি সেট:
  • কোন নির্দিষ্ট ট্রিগার ডেটাতে এই বৈশিষ্ট্যটি প্রযোজ্য। এই উত্সটি শুধুমাত্র সেই ট্রিগারগুলির সাথে মেলে যা trigger_specs এ নির্দিষ্ট trigger_data মানগুলির একটি রয়েছে। অন্য কথায়, যদি ট্রিগারটি এই উৎসের সাথে মিলে যেত কিন্তু এর trigger_data উৎসের কনফিগারেশনের মানগুলির মধ্যে একটি না হয়, তাহলে ট্রিগারটিকে উপেক্ষা করা হয়।
  • যখন একটি নির্দিষ্ট ট্রিগার এই বৈশিষ্ট্যের সাথে মেলে ( event_report_windows ব্যবহার করে)। উল্লেখ্য যে আগে উল্লিখিত দুটি ম্যাচের মানদণ্ডে ব্যর্থ হওয়া সত্ত্বেও ট্রিগারটি সমষ্টিগত প্রতিবেদনের জন্য একটি উত্সের সাথে মিলিত হতে পারে।
• একটি অ্যাট্রিবিউশন উইন্ডোর মধ্যে সমস্ত ট্রিগারের সারসংক্ষেপ এবং বাকেটাইজ করার জন্য একটি নির্দিষ্ট অ্যালগরিদম। এটি ট্রিগারগুলিকে একটি value পরামিতি নির্দিষ্ট করতে দেয় যা একটি নির্দিষ্ট স্পেকের জন্য সংক্ষিপ্ত হয়, কিন্তু একটি বালতি মান হিসাবে রিপোর্ট করা হয়।

দ্রষ্টব্য: এই মিলিত মানদণ্ডগুলি একটি নির্দিষ্ট উত্সে একটি ট্রিগারকে দায়ী করার পরে সঞ্চালিত হয়৷ যদি কোনো উৎসের জন্য trigger_specs নির্দিষ্ট করা থাকে এবং অ্যাট্রিবিউশনের পরে কোনো মিলিত বৈশিষ্ট্য না পাওয়া যায়, তাহলে ট্রিগার উপেক্ষা করা হয়।

ট্রিগারগুলি event_trigger_data মধ্যে অভিধানে একটি ঐচ্ছিক মান প্যারামিটার যোগ করতেও সমর্থন করবে।

{
  "event_trigger_data": [
    {
      "trigger_data": "2",
      "value": 100,  // Defaults to 1
      "filters": ...
    },
    ...
  ]
}

প্রতিটি ট্রিগার নিবন্ধন সর্বাধিক একটি ট্রিগার বৈশিষ্ট্যের সাথে মিলবে এবং এর সম্পর্কিত সারাংশ মান আপডেট করবে। উচ্চ স্তরে, ট্রিগার সময়ে আমরা করব:

• গ্লোবাল অ্যাট্রিবিউশন ফিল্টার প্রয়োগ করুন।
• প্রতিটি ট্রিগার স্পেকের জন্য, স্পেকের event_reporting_window ব্যবহার করে একটি মিল খুঁজে পেতে স্পেকটিতে event_trigger_data মূল্যায়ন করুন। কোনো ট্রিগার স্পেক অনুপস্থিত event_report_windows সাব-ফিল্ডের ক্ষেত্রে শীর্ষ স্তরের event_reporting_windows একটি ডিফল্ট মান হিসাবে কাজ করে।
• প্রথম মিলে যাওয়া স্পেকটি অ্যাট্রিবিউশনের জন্য বেছে নেওয়া হয়, এবং সারাংশের মান value দ্বারা বৃদ্ধি করা হয়।

যখন একটি স্পেকের জন্য event_report_window সম্পূর্ণ হয়, তখন আমরা একটি বালতিতে এর সারাংশ মান ম্যাপ করব এবং অ্যাট্রিবিউটেড ট্রিগার মানের কারণে সারাংশ বাকেটের প্রতিটি বৃদ্ধির জন্য একটি ইভেন্ট-লেভেল রিপোর্ট পাঠাব। একটি অতিরিক্ত ফিল্ড সহ রিপোর্ট আসবে, trigger_summary_bucket ।

{
  ...
  "trigger_summary_bucket": [<bucket start>, <bucket end>],
}

বর্তমান সংস্করণের সমতুল্য কনফিগারেশন

নিম্নলিখিতগুলি যথাক্রমে API-এর বর্তমান ইভেন্ট এবং নেভিগেশন উত্সগুলির জন্য সমতুল্য কনফিগারেশন। বিশেষ করে নেভিগেশন উত্সগুলির জন্য, এটি ব্যাখ্যা করে যে একই এপিসিলন মান বজায় রাখার জন্য ইভেন্ট উত্সের তুলনায় শব্দের মাত্রা এত বেশি কেন: নেভিগেশন উত্সগুলির একটি অনেক বড় আউটপুট স্থান রয়েছে।

এটা সম্ভব যে সমতুল্য একাধিক কনফিগারেশন আছে, কিছু প্যারামিটার ডিফল্ট হিসাবে সেট করা বা ছাঁটাই করা যেতে পারে।

সমতুল্য ইভেন্ট উত্স

// Note: most of the fields here are not required to be explicitly listed.
// Here we list them explicitly just for clarity.
{
  "trigger_specs": [
  {
    "trigger_data": [0, 1],
    "event_report_windows": {
      "end_times": [<30 days>]
    },
    "summary_window_operator": "count",
    "summary_buckets": [1],
  }],
  "max_event_level_reports": 1,
  ...
  // expiry must be greater than or equal to the last element of the end_times
  "expiry": <30 days>,
}

সমতুল্য নেভিগেশন উত্স

// Note: most of the fields here are not required to be explicitly listed.
// Here we list them explicitly just for clarity.
{
  "trigger_specs": [
  {
    "trigger_data": [0, 1, 2, 3, 4, 5, 6, 7],
    "event_report_windows": {
      "end_times": [<2 days>, <7 days>, <30 days>]
    },
    "summary_window_operator": "count",
    "summary_buckets": [1, 2, 3],
  }],
  "max_event_level_reports": 3,
  ...
  // expiry must be greater than or equal to the last element of the end_times
  "expiry": <30 days>,
}

কাস্টম কনফিগারেশনের উদাহরণ

নীচে ডিফল্টের বাইরে কিছু অতিরিক্ত কনফিগারেশন রয়েছে। এই সমস্ত উদাহরণে, বিকাশকারী ট্রেড-অফগুলি অন্তর্ভুক্ত করে:

• শব্দের মাত্রা রক্ষা করার জন্য ডিফল্ট কনফিগারেশনের কিছু মাত্রা হ্রাস করা (#ট্রিগার, ট্রিগার ডেটা কার্ডিনালিটি, #উইন্ডোজ)
• শব্দের মাত্রা কমানোর জন্য ডিফল্ট কনফিগারেশনের কিছু মাত্রা হ্রাস করা (#ট্রিগার, ট্রিগার ডেটা কার্ডিনালিটি, # উইন্ডোজ)

ট্রিগার মান বালতি রিপোর্ট করুন

এই উদাহরণ কনফিগারেশনটি এমন একজন ডেভেলপারকে সমর্থন করে যিনি শুধুমাত্র একটি রিপোর্টিং উইন্ডোর (যেমন 7 দিন) জন্য মান ডেটার জন্য অপ্টিমাইজ করতে চান, কম শব্দের জন্য কম রিপোর্টিং উইন্ডোতে ট্রেড করুন৷ এই উদাহরণে trigger_data ০ ব্যতীত অন্য কোনো মান সেট করে এমন যেকোনো ট্রিগার অ্যাট্রিবিউশনের জন্য অযোগ্য।

{
  "trigger_specs": [
  {
    "trigger_data": [0],
    "event_report_windows": {
      "end_times": [604800, 1209600] // 7 days, 14 days represented in seconds
    },
    "summary_window_operator": "value_sum",
    "summary_buckets": [5, 10, 100]
  }],
}

ট্রিগারগুলি value ক্ষেত্রের সেটের সাথে নিবন্ধিত হতে পারে, যা সংক্ষিপ্ত করা হয় এবং বাকেট করা হয়। উদাহরণস্বরূপ যদি 1, 3 এবং 4 মান সহ উত্স নিবন্ধনের 7 দিনের মধ্যে তিনটি ট্রিগার থাকে৷

{ "event_trigger_data": [{"trigger_data": "0", "value": 1}] }
{ "event_trigger_data": [{"trigger_data": "0", "value": 3}] }
{ "event_trigger_data": [{"trigger_data": "0", "value": 4}] }

মানগুলিকে 8 এ যোগ করা হয়েছে এবং 7 দিন + 1 ঘন্টা পরে নিম্নলিখিত প্রতিবেদনগুলিতে রিপোর্ট করা হয়েছে:

// Report 1
{
  ...
  "trigger_summary_bucket": [5, 9]
}

পরবর্তী 7 দিনে, নিম্নলিখিত ট্রিগারগুলি নিবন্ধিত হয়েছে:

{ "event_trigger_data": [{"trigger_data": "0", "value": 50}] }
{ "event_trigger_data": [{"trigger_data": "0", "value": 45}] }

মানগুলি 8 + 50 + 45 = 103 এ যোগ করা হয়েছে। এটি 14 দিন + 1 ঘন্টায় নিম্নলিখিত রিপোর্টগুলি প্রদান করে:

// Report 2
{
  ...
  "trigger_summary_bucket": [10, 99]
},

// Report 3
{
  ...
  "trigger_summary_bucket": [100, MAX_INT]
}

ট্রিগার সংখ্যা রিপোর্ট করুন

এই উদাহরণটি দেখায় যে কীভাবে একজন বিকাশকারী 10 পর্যন্ত ট্রিগারের গণনা পেতে একটি উত্স কনফিগার করতে পারে।

{
  "trigger_specs": [
  {
    "trigger_data": [0],
    "event_report_windows": {
      "end_times": [604800] // 7 days represented in seconds
    },
    // This field could be omitted to save bandwidth since the default is "count"
    "summary_window_operator": "count",
    "summary_buckets": [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
  }],
}

trigger_data 0-এ সেট করা অ্যাট্রিবিউটেড ট্রিগারগুলিকে গণনা করা হয় এবং 10-এ ক্যাপ করা হয়। summary_window_operator গণনা করার জন্য সেট করা থাকায় ট্রিগার মান উপেক্ষা করা হয়। যদি 4টি ট্রিগার নিবন্ধিত হয় এবং উত্সের জন্য দায়ী করা হয়, প্রতিবেদনটি দেখতে এইরকম হবে:

// Report 1
{
  ...
  "trigger_summary_bucket": [1, 1]
}
// Report 2
{
  ...
  "trigger_summary_bucket": [2, 2]
}
// Report 3
{
  ...
  "trigger_summary_bucket": [3, 3]
}
// Report 4
{
  ...
  "trigger_summary_bucket": [4, 4]
}

আরো ঘন ঘন রিপোর্টিং সঙ্গে বাইনারি

এই উদাহরণ কনফিগারেশনটি এমন একজন বিকাশকারীকে সমর্থন করে যিনি প্রথম 10 দিনে অন্তত একটি রূপান্তর ঘটেছে কিনা তা জানতে চান (মূল্য নির্বিশেষে), কিন্তু ডিফল্টের চেয়ে বেশি ঘন ঘন ব্যবধানে রিপোর্ট পেতে চায়। আবার, এই উদাহরণে যে কোনো ট্রিগার যা trigger_data 0 ব্যতীত অন্য কোনো মান নির্ধারণ করে তা অ্যাট্রিবিউশনের জন্য অযোগ্য। এই কারণেই এই ব্যবহারের ক্ষেত্রে বাইনারি হিসাবে উল্লেখ করা হয়।

{
  "trigger_specs": [
  {
    "trigger_data": [0],
    "event_report_windows": {
      // 1 day, 2 days, 3 days, 5 days, 7 days, 10 days represented in seconds
      "end_times": [86400, 172800, 259200, 432000, 604800, 864000]
    },
    // This field could be omitted to save bandwidth since the default is "count"
    "summary_window_operator": "count",
    "summary_buckets": [1]
  }],
}

উৎস থেকে উৎসে ট্রিগার স্পেস পরিবর্তন করুন

দ্রষ্টব্য: trigger_specs নিবন্ধন উৎস থেকে উৎসে ভিন্ন হতে পারে। এই উদাহরণে দুটি কনফিগারেশন রয়েছে, একটি যেটি নির্দিষ্ট করে যে শুধুমাত্র 0 থেকে 3 পর্যন্ত trigger_data মান সহ ট্রিগারগুলিই অ্যাট্রিবিউশনের জন্য যোগ্য এবং আরেকটি যেটি নির্দিষ্ট করে যে শুধুমাত্র 4 থেকে 7 পর্যন্ত trigger_data মান সহ ট্রিগারগুলিই যোগ্য৷ ব্যবহারকারী তাদের অর্ধেক উত্স পূর্বের সাথে এবং অর্ধেক তাদের উত্স পরেরটির সাথে কনফিগার করতে পারে। এটি করার ফলে রিপোর্টে যোগ করা গোলমাল নেভিগেশন উত্সের জন্য ডিফল্ট কনফিগারেশনের প্রায় 15% নয়।

{
  "trigger_specs": [
  {
    "trigger_data": [0, 1, 2, 3],
    "event_report_windows": {
      "end_times": [172800, 604800, 2592000] // 2 days, 7 days, 30 days represented in seconds
    }
  }],
  "max_event_level_reports": 3
}

{
  "trigger_specs": [
  {
    "trigger_data": [4, 5, 6, 7],
    "event_report_windows": {
      "end_times": [172800, 604800, 2592000] // 2 days, 7 days, 30 days represented in seconds
    }
  }],
  "max_event_level_reports": 3
}

আমরা বিকাশকারীদের এই API এক্সটেনশনের জন্য বিভিন্ন ব্যবহারের ক্ষেত্রে পরামর্শ দিতে উত্সাহিত করি এবং আমরা এই ব্যাখ্যাকারীকে সেই ব্যবহারের ক্ষেত্রে নমুনা কনফিগারেশন সহ আপডেট করব।

রিডাইরেক্ট ছাড়াই ক্রস নেটওয়ার্ক অ্যাট্রিবিউশন

বিজ্ঞাপন প্রযুক্তিগুলিকে একাধিক অ্যাট্রিবিউশন সোর্স ট্রিগার নিবন্ধন করতে এবং ক্রস-নেটওয়ার্ক অ্যাট্রিবিউশন সম্পাদন করতে রিডাইরেক্ট ব্যবহার করা উচিত। এই বৈশিষ্ট্যটি ক্রস-নেটওয়ার্ক অ্যাট্রিবিউশনকে সমর্থন করে যেখানে নেটওয়ার্ক জুড়ে রিডাইরেক্ট করা সম্ভব নয়। আরও জানুন

বিজ্ঞাপন প্রযুক্তিগুলি ট্রিগার রেজিস্ট্রেশন প্রতিক্রিয়াতে কনফিগারেশন পাঠাতে পারে যার উপর ভিত্তি করে অন্যান্য বিজ্ঞাপন প্রযুক্তি দ্বারা নিবন্ধিত উত্সগুলি প্রাপ্ত উত্স তৈরি করতে নির্বাচন করা হয়; এই প্রাপ্ত উত্স তারপর বৈশিষ্ট্য জন্য ব্যবহার করা হয়. যদি ট্রিগারটি প্রাপ্ত উত্সের জন্য দায়ী করা হয় তবে সমষ্টিগত প্রতিবেদন তৈরি করা হয়। প্রাপ্ত উত্সগুলির জন্য ইভেন্ট রিপোর্ট তৈরি করা সমর্থিত নয়৷

বিজ্ঞাপন প্রযুক্তিগুলি তাদের নিবন্ধিত উত্সগুলির aggregation_keys থেকে বেছে নিতে পারে যা তারা অংশীদার বিজ্ঞাপন প্রযুক্তির সাথে ভাগ করতে চায়৷ এই কীগুলি ঐচ্ছিক shared_aggregation_keys ফিল্ডে ঘোষণা করা যেতে পারে, সোর্স রেজিস্ট্রেশন হেডার Attribution-Reporting-Register-Source অধীনে অবস্থিত:

"shared_aggregation_keys": ["[key name1]", "[key name2]"]

ট্রিগার রেজিস্ট্রেশন হেডার Attribution-Reporting-Register-Trigger অধীনে কনফিগারেশনের উপর ভিত্তি করে প্রাপ্ত উত্সগুলি তৈরি করা হয়:

  // Specifies the configuration based on which derived sources should be
  // generated. Those derived sources will be included for source matching at the
  // time of attribution. For example, if adtech2 is registering a trigger with an
  // attribution_config with source_network as adtech1, available sources
  // registered by adtech1 will be considered with additional filtering criteria
  // applied to that set as mentioned in the attribution_config. Derived
  // sources can have different values to priority, post_install_exclusivity_window
  // etc.

  "attribution_config": [
    {
      // Derived sources are created from this adtech's registered sources
      "source_network": "[original source's adtech enrollment ID]",
      //(optional) Filter sources whose priority falls in this range
      "source_priority_range": {
        "start": [priority filter lower bound],
        "end": [priority filter upper bound]
      },
      // (optional) Filter sources whose at least one of filter maps matches these
      // filters
      "source_filters": {
        "key name 1": ["key1 value 1"]
      },
      // (optional) Filter sources whose none of filter map matches these
      // filters
        "source_not_filters": {
          "key name 1": ["key1 value 1"]
        },
      // (optional) Apply this priority to the generated derived sources
      "priority": "[64 bit signed integer]",
      // (optional) The derived source will have expiry set as this or parent
      // source's, whichever is earlier
      "expiry": "[64 bit signed integer]",
      // (optional) set on the derived source
      "filter_data": {
        "key name 1": ["key1 value 1"]
      },
      // (optional) set on the derived source
      "post_install_exclusivity_window": "[64-bit unsigned integer]"
    }
  ]

এখানে উদাহরণ মান যুক্ত একটি সংস্করণ আছে:

  "attribution_config": [
    {
      "source_network": "adtech1-enrollment-id",
      "source_priority_range": {
        "start": 50,
        "end": 100
      },
      "source_filters": {
        "source_type": ["NAVIGATION"]
      },
      "source_not_filters": {
        "product_id": ["789"]
      },
      "priority": "30",
      "expiry": "78901",
      // (optional) set on the derived source
      "filter_data": {
        "product_id": ["1234"]
        },
      // (optional) set on the derived source
      "post_install_exclusivity_window": "7890"
    }
  ]

দুটি নতুন ঐচ্ছিক ক্ষেত্র নিবন্ধন শিরোনাম ট্রিগার যোগ করা হয়. এই ক্ষেত্রগুলি সমষ্টিগত রিপোর্ট কীগুলিতে বিজয়ী বিজ্ঞাপন প্রযুক্তির শনাক্তকারীকে সক্ষম করে:

• x_network_bit_mapping : বিজ্ঞাপন প্রযুক্তি শনাক্তকারী বিট ম্যাপিং-এ তালিকাভুক্তি আইডি
• x_network_data : বিজয়ী বিজ্ঞাপন প্রযুক্তির x_network_bit_mapping বা ট্রিগার কী অংশের সাথে অপারেশনের জন্য অফসেট (বাম শিফট)

উদাহরণ:

"Attribution-Reporting-Register-Trigger": {
  "attribution_config": [...],
  "aggregatable_trigger_data": [
    {
     "key_piece": "0x400",
     "source_keys": ["campaignCounts"]
      "x_network_data" : {
        "key_offset" : 12 // [64 bit unsigned integer]
      }
    }
    …
  ]
  …
  "x_network_bit_mapping": {
   // This mapping is used to generate trigger key pieces with AdTech identifier
   // bits. eg. If AdTechA's sources wins the attribution then 0x1 here will be
   // OR'd with the trigger key pieces to generate the final key piece.
    "AdTechA-enrollment_id": "0x1", // Identifier bits in hex for A
    "AdTechB-enrollment_id": "0x2"  // Identifier bits in hex for B
  }
  …
}

AdTechB-এর উৎসের জন্য রিপোর্ট তৈরি করার সময় ট্রিগার কী-পিস গণনা করা হল:

• key_piece : 0x400 (010000000000)
• key_offset : 12
• AdtechB এর enrollment_id মান: 2 (010) ( x_network_bit_mapping থেকে)
• ফলাফল ট্রিগার কী টুকরা: 0x400 | 0x2 << 12 = 0x2400

সীমাবদ্ধতা

SDK রানটাইমের জন্য চলমান ক্ষমতার তালিকার জন্য, রিলিজ নোটগুলি দেখুন।

বাগ এবং সমস্যা রিপোর্ট করুন

আপনার প্রতিক্রিয়া Android এ গোপনীয়তা স্যান্ডবক্সের একটি গুরুত্বপূর্ণ অংশ! Android-এ গোপনীয়তা স্যান্ডবক্সের উন্নতির জন্য আপনার খুঁজে পাওয়া যেকোন সমস্যা বা ধারণা সম্পর্কে আমাদের জানান।