واجهة برمجة تطبيقات CrUX History

تتيح واجهة برمجة التطبيقات CrUX History API الوصول بسرعة إلى وقت استجابة سريع لبيانات تجربة المستخدم الفعلي السابقة على مستوى الصفحة والمصادر على مدى ستة أشهر.

حالة الاستخدام الشائعة

تتيح واجهة برمجة التطبيقات CrUX History API طلب البحث عن مقاييس تجربة المستخدم السابقة لمعرّف موارد منتظم (URI) محدّد، مثل "الحصول على مؤشرات تجربة المستخدم السابقة لمصدر https://example.com".

تتّبع History API البنية نفسها المتّبعة في CrUX API اليومية باستثناء القيم التي يتم تقديمها في مصفوفة، ويتم تصنيف المفاتيح بأسماء جمع (على سبيل المثال، histogramTimeseries بدلاً من histogram أو p75s بدلاً من p75).

مفتاح واجهة برمجة تطبيقات CrUX

ومثل واجهة برمجة التطبيقات اليومية، يتطلب استخدام CrUX History API مفتاح Google Cloud. ويمكن استخدام المفتاح نفسه لواجهة برمجة التطبيقات Daily and History API.

يمكنك إنشاء حساب في صفحة بيانات الاعتماد وتوفيره لاستخدام Chrome UX Report API.

بعد الحصول على مفتاح واجهة برمجة التطبيقات، يمكن لتطبيقك إلحاق مَعلمة طلب البحث key=[YOUR_API_KEY] بجميع عناوين URL للطلبات. ويمكنك الاطّلاع على أمثلة على طلبات البحث.

يمكن تضمين مفتاح واجهة برمجة التطبيقات في عناوين URL بشكل آمن ولا يحتاج إلى أي ترميز.

نموذج البيانات

يوضح هذا القسم بالتفصيل هيكل البيانات في الطلبات والردود.

تسجيل

تمثّل هذه السمة معلومة منفصلة حول صفحة أو موقع إلكتروني. يمكن أن يحتوي السجل على بيانات خاصة بأحد المعرّفات ولمجموعة معيّنة من السمات. يمكن أن يحتوي السجلّ على بيانات لمقياس واحد أو أكثر.

المعرّفات

تحدد المعرّفات السجلات التي يجب البحث عنها. في تقرير تجربة المستخدم على Chrome، هذه المعرّفات هي صفحات الويب والمواقع الإلكترونية.

الأصل

عندما يكون المعرّف مصدرًا، يتم تجميع كل البيانات المتوفّرة لكل الصفحات في ذلك المصدر معًا. على سبيل المثال، لنفترض أنّ أصل http://www.example.com يحتوي على صفحات كما هو موضّح في خريطة الموقع هذه:

http://www.example.com/
http://www.example.com/foo.html
http://www.example.com/bar.html

وهذا يعني أنّه عند إجراء طلب بحث في تقرير تجربة المستخدم من Chrome مع ضبط المصدر على http://www.example.com، سيتم عرض بيانات http://www.example.com/ وhttp://www.example.com/foo.html وhttp://www.example.com/bar.html مجمّعة معًا، لأنّ هذه هي كل الصفحات التي تندرج ضمن هذا المصدر.

عناوين URL

وعندما يكون المُعرف عنوان URL، لن يتم عرض سوى البيانات الخاصة بعنوان URL المحدّد. جارٍ البحث مرّة أخرى في خريطة الموقع المصدر الخاصة بـ http://www.example.com:

http://www.example.com/
http://www.example.com/foo.html
http://www.example.com/bar.html

في حال ضبط المعرّف على عنوان URL بالقيمة http://www.example.com/foo.html، لن يتمّ عرض سوى بيانات تلك الصفحة.

الأبعاد

تحدد السمات مجموعة معيّنة من البيانات يتم تجميع سجلّ بناءً عليها. على سبيل المثال، يشير شكل الجهاز PHONE إلى أنّ السجلّ يحتوي على معلومات حول عمليات التحميل التي تمت على جهاز جوّال.

لا تتوفّر واجهة برمجة التطبيقات CrUX History API إلا بشكل مجمَّع حسب سمة شكل الجهاز. هذه فئة عامة من الأجهزة مقسّمة إلى PHONE وTABLET وDESKTOP.

المقياس

ننشئ تقارير عن المقاييس في السلاسل الزمنية للتجميعات الإحصائية، وهي المدرّجات التكرارية والنسب المئوية والكسور.

المدرجات التكرارية

عند التعبير عن المقاييس في صفيف مدرّج تكراري، يمثّل كل إدخال في السلسلة الزمنية النسبة المئوية لعمليات تحميل الصفحة التي وقع فيها المقياس في فاصل زمني، بالتناسب مع الجميع. يتمّ عرض نقاط البيانات بترتيب تواريخ فترة جمع البيانات التي تعرضها واجهة برمجة التطبيقات أيضًا، وتكون النقطة الأولى هي الفترة الأقدم، والنقطة الأخيرة هي أحدث فترة جمع.

يظهر المدرّج التكراري البسيط المكون من ثلاثة سلال لمثال مقياس على النحو التالي:

{
  "histogramTimeseries": [
    {
      "start": 0,
      "end": 2500,
      "densities": [0.9190, 0.9203, 0.9194, 0.9195, 0.9183, 0.9187]
    },
    {
      "start": 2500,
      "end": 4000,
      "densities": [0.0521, 0.0513, 0.0518, 0.0518, 0.0526, 0.0527]
    },
    {
      "start": 4000,
      "densities": [0.0288, 0.0282, 0.0286, 0.0285, 0.0290, 0.0285]
    }
  ],
}

تشير هذه البيانات إلى أنّ% 91.90 من عمليات تحميل الصفحات قد شهدت مثال قيمة المقياس بين 0 ملي ثانية و2,500 ملي ثانية لأول عملية جمع في السجلّ، تليها %92.03 ثم %91.94... لا يتم تضمين وحدات المقياس في هذا المدرج التكراري، وفي هذه الحالة سنفترض بالمللي ثانية.

بالإضافة إلى ذلك، شهدت 5.21% من عمليات تحميل الصفحات مثال على قيمة المقياس التي تتراوح بين 2,500 و4,000 ملي ثانية في أول فترة جمع في السجلّ، وشهدت 2.88% من عمليات تحميل الصفحات قيمة أكبر من 4,000 ملي ثانية في فترة جمع البيانات الأولى في السجلّ.

الشرائح المئوية

قد تحتوي المقاييس أيضًا على سلاسل زمنية لشرائح مئوية يمكن أن تكون مفيدة لإجراء تحليل إضافي.

يتمّ عرض نقاط البيانات بترتيب تواريخ فترة جمع البيانات التي تعرضها واجهة برمجة التطبيقات أيضًا، وتكون النقطة الأولى هي الفترة الأقدم، والنقطة الأخيرة هي أحدث فترة جمع.

{
  "percentilesTimeseries": {
    "p75s": [1362, 1352, 1344, 1356, 1366, 1377]
  },
}

ويمكن أن تعرض هذه الشرائح المئوية قيمًا مقياسًا محدَّدة بالشريحة المئوية المحدّدة لذلك المقياس. وهي تستند إلى المجموعة الكاملة من البيانات المتاحة وليس إلى البيانات المجمعة النهائية، لذا فهي لا تتطابق بالضرورة مع نسبة مئوية تم استقراءها تستند إلى المدرج التكراري المجمَّع النهائي.

الكسور

ويمكن التعبير عن المقاييس كسلسلة زمنية لكسور مصنفة؛ ويصف كل تصنيف تحميل الصفحة بطريقة معينة. يتمّ عرض نقاط البيانات بترتيب تواريخ فترة جمع البيانات التي تعرضها واجهة برمجة التطبيقات أيضًا، وتكون النقطة الأولى هي الفترة الأقدم، والنقطة الأخيرة هي أحدث فترة جمع.

مثال:

{    
  "fractionTimeseries": {
    "desktop": {"fractions": [0.3195, 0.2115, 0.1421]},
    "phone": {"fractions": [0.6295, 0.7544, 0.8288]},
    "tablet": {"fractions": [0.051, 0.0341, 0.029]}
  }
}

في هذا المثال، تشير أحدث نقطة بيانات إلى أنّ% 14.21 من عمليات تحميل الصفحات كانت صادرة من أجهزة الكمبيوتر المكتبي، في حين أنّ% 82.88 من عمليات تحميل الصفحات مصدرها الهواتف.

أنواع قيم المقاييس

بما أنّ واجهة برمجة التطبيقات CrUX History API تستخدم أنواع قيم المقاييس نفسها، يمكنك الرجوع إلى مستندات أنواع قيم مقاييس CrUX API اليومية للحصول على مزيد من التفاصيل.

الأهلية لاستخدام المقاييس

استنادًا إلى معايير الأهلية، قد يكون المصدر أو عنوان URL مؤهَّلاً فقط لبعض فترات جمع البيانات التي تغطيها واجهة برمجة التطبيقات CrUX History API. في هذه الحالات، ستعرض واجهة برمجة التطبيقات CrUX History API "NaN" لكثافة histogramTimeseries وnull للفترات percentilesTimeseries التي لا تتضمّن بيانات مؤهَّلة. ويرجع سبب الاختلاف إلى أنّ كثافات المدرج التكراري هي دائمًا أرقام، في حين يمكن أن تكون الشرائح المئوية أرقامًا أو سلاسل (يستخدم متغيّرات التصميم التراكمية سلاسل، حتى إذا كانت تشبه أرقامًا).

على سبيل المثال، إذا لم تتضمّن الفترة الثانية أي بيانات مؤهَّلة، ستظهر على النحو التالي:

{
  "histogramTimeseries": [
    {
      "start": 0,
      "end": 2500,
      "densities": [0.9190, "NaN", 0.9194, 0.9195, 0.9183, 0.9187]
    },
    {
      "start": 2500,
      "end": 4000,
      "densities": [0.0521, "NaN", 0.0518, 0.0518, 0.0526, 0.0527]
    },
    {
      "start": 4000,
      "densities": [0.0288, "NaN", 0.0286, 0.0285, 0.0290, 0.0285]
    }
  ],
  "percentilesTimeseries": {
    "p75s": [1362, null, 1344, 1356, 1366, 1377]
  },
}

بالنسبة إلى عناوين URL أو المصادر التي تدخل في أهلية وأهلية إجرائها بمرور الوقت، قد تلاحظ أنّ العديد من الإدخالات غير مكتملة.

فترات جمع البيانات

تحتوي واجهة برمجة التطبيقات CrUX History API على عنصر collectionPeriods مع مصفوفة من حقول firstDate وendDate تمثل تاريخَي البدء والانتهاء لكل نافذة تجميع. مثال:

    "collectionPeriods": [{
        "firstDate": { "year": 2022, "month": 7, "day": 10 },
        "lastDate": { "year": 2022, "month": 8, "day": 6 }
      }, {
        "firstDate": { "year": 2022, "month": 7, "day": 17 },
        "lastDate": { "year": 2022, "month": 8, "day": 13 }
      }, {
        "firstDate": { "year": 2022, "month": 7, "day": 24 },
        "lastDate": { "year": 2022, "month": 8, "day": 20 }
      }, {
        "firstDate": { "year": 2022, "month": 7, "day": 31 },
        "lastDate": { "year": 2022, "month": 8, "day": 27 }
      }, {
        "firstDate": { "year": 2022, "month": 8, "day": 7 },
        "lastDate": { "year": 2022, "month": 9, "day": 3 }
      }, {
        "firstDate": { "year": 2022, "month": 8, "day": 14 },
        "lastDate": { "year": 2022, "month": 9, "day": 10 }
      }
    ]

ويتم ترتيب فترات جمع البيانات هذه تصاعديًا وتمثّل النطاق الزمني لكل نقطة من نقاط البيانات في الأقسام الأخرى من الردّ.

يتم تعديل History API كل يوم اثنين وتحتوي على بيانات حتى يوم السبت السابق (وفقًا للتأخير العادي لمدة يومين). يحتوي على بيانات آخر 25 أسبوعًا - فترة جمع واحدة كل أسبوع.

ولأنّ كل فترة جمع تتضمّن البيانات المجمّعة السابقة التي تبلغ 28 يومًا، تكون فترات جمع البيانات حسب الأسبوع، ما يعني أنّ فترات جمع البيانات ستتداخل. وهي تشبه المتوسط المتحرك للبيانات، مع تضمين بيانات تعادل ثلاثة أسابيع في كل فترة لاحقة، وأسبوع واحد مختلف.

أمثلة على طلبات البحث

يتم إرسال طلبات البحث ككائنات JSON باستخدام طلب POST إلى https://chromeuxreport.googleapis.com/v1/records:queryHistoryRecord?key=[YOUR_API_KEY]" مع بيانات طلب البحث ككائن JSON في نص POST.

يُرجى التنبّه إلى استخدام queryHistoryRecord بدلاً من queryRecord في CrUX API يوميًا.

مثال على النص:

{
  "origin": "https://example.com",
  "formFactor": "PHONE",
  "metrics": [
    "largest_contentful_paint",
    "experimental_time_to_first_byte"
  ]
}

على سبيل المثال، يمكن طلب ذلك من curl باستخدام سطر الأوامر التالي (مع استبدال API_KEY بمفتاحك):

curl -s --request POST 'https://chromeuxreport.googleapis.com/v1/records:queryHistoryRecord?key=API_KEY' \
    --header 'Accept: application/json' \
    --header 'Content-Type: application/json' \
    --data '{"formFactor":"PHONE","origin":"https://www.example.com","metrics":["largest_contentful_paint", "experimental_time_to_first_byte"]}'

تتوفر البيانات على مستوى الصفحة من خلال واجهة برمجة التطبيقات عن طريق تمرير السمة url في طلب البحث، بدلاً من origin:

{
  "url": "https://example.com/page",
  "formFactor": "PHONE",
  "metrics": [
    "largest_contentful_paint",
    "experimental_time_to_first_byte"
  ]
}

إذا لم يتم ضبط السمة metrics، سيتم عرض جميع المقاييس المتاحة:

• cumulative_layout_shift
• first_contentful_paint
• first_input_delay
• interaction_to_next_paint
• largest_contentful_paint
• experimental_time_to_first_byte
• navigation_types
• form_factors (يتم الإبلاغ فقط في حال عدم تحديد formFactor في الطلب)

في حال عدم تقديم قيمة formFactor، سيتم تجميع القيم في جميع أشكال الأجهزة.

يمكنك الاطّلاع على دليل استخدام واجهة برمجة التطبيقات CrUX History API للحصول على مزيد من الأمثلة على طلبات البحث.

مسار البيانات

تتم معالجة مجموعة بيانات "تقرير تجربة المستخدم على Chrome" من خلال مسار لدمج البيانات وتجميعها وتصفيتها قبل أن تصبح متاحة من خلال واجهة برمجة التطبيقات.

متوسط التحرك

البيانات الواردة في تقرير تجربة المستخدم على Chrome هي متوسط التحرك خلال 28 يومًا للمقاييس المجمّعة. وهذا يعني أنّ البيانات المقدَّمة في "تقرير تجربة المستخدم على Chrome" في أي وقت هي البيانات المجمّعة معًا خلال آخر 28 يومًا.

تحتوي History API على عدد من فترات جمع البيانات، تمتد كل منها على هذه الفترات التي تبلغ 28 يومًا. ولأنّ كل فترة جمع تتضمّن البيانات المجمّعة السابقة التي تبلغ 28 يومًا، تكون فترات جمع البيانات حسب الأسبوع، ما يعني أنّ فترات جمع البيانات ستتداخل. وهي تشبه المتوسط المتحرك للبيانات، مع تضمين بيانات تعادل ثلاثة أسابيع في كل فترة لاحقة، وأسبوع واحد مختلف.

التحديثات الأسبوعية

يتم تعديل History API كل يوم اثنين حوالي الساعة 04:00 حسب التوقيت العالمي المنسَّق (UTC) وتحتوي على بيانات حتى يوم السبت السابق (وفقًا للتأخير العادي لمدة يومين). يحتوي هذا المشروع على بيانات آخر 25 أسبوعًا (6 أشهر تقريبًا)، أي فترة جمع واحدة كل أسبوع.

لا توجد اتفاقية مستوى خدمة خاصة بأوقات التحديث، ويتم العمل على أساس أفضل بذل كل يوم.

المخطّط

هناك نقطة نهاية واحدة لواجهة برمجة تطبيقات CrUX History API التي تقبل طلبات HTTP POST. تعرض واجهة برمجة التطبيقات record يحتوي على عنصر metrics واحد أو أكثر يتوافق مع بيانات الأداء حول المصدر أو الصفحة المطلوبة.

طلب HTTP

POST https://chromeuxreport.googleapis.com/v1/records:queryHistoryRecord

يستخدم عنوان URL بنية تحويل الترميز gRPC.

نص الطلب

تستخدم واجهة برمجة التطبيقات CrUX History API نصوص الطلبات نفسها التي تستخدمها واجهة برمجة تطبيقات CrUX API اليومية، باستثناء عدم إتاحة حقل الطلب effectiveConnectionType.

على سبيل المثال، لطلب قيم "سرعة عرض أكبر جزء من المحتوى على سطح المكتب" على صفحة web.dev الرئيسية:

{
  "origin": "https://web.dev/",
  "formFactor": "DESKTOP",
  "metrics": [
    "largest_contentful_paint"
  ]
}

نص الاستجابة

تعرض الطلبات الناجحة استجابات تحتوي على كائن record وurlNormalizationDetails بالبنية التالية:

{
  "record": {
    "key": {
      object (Key)
    },
    "metrics": [
      string: {
        object (Metric)
      }
    ]
  },
  "urlNormalizationDetails": {
    object (UrlNormalization)
  }
}

على سبيل المثال، يمكن أن يكون الرد على نص الطلب في الطلب السابق:

{
  "record": {
    "key": {
      "origin": "https://web.dev"
    },
    "metrics": {
      "largest_contentful_paint": {
        "histogramTimeseries": [{
            "start": 0, "end": 2500, "densities": [
              0.9190, 0.9203, 0.9194, 0.9195, 0.9183, 0.9187, ...
            ]
          }, {
            "start": 2500, "end": 4000, "densities": [
              0.0521, 0.0513, 0.0518, 0.0518, 0.0526, 0.0527, ...
            ]
          },  {
            "start": 4000, "densities": [
              0.0288, 0.0282, 0.0286, 0.0285, 0.0290, 0.0285, ...
            ]
          }
        ],
        "percentilesTimeseries": {
          "p75s": [
            1362, 1352, 1344, 1356, 1366, 1377, ...
          ]
        }
      }
    },
    "collectionPeriods": [{
        "firstDate": { "year": 2022, "month": 7, "day": 10 },
        "lastDate": { "year": 2022, "month": 8, "day": 6 }
      }, {
        "firstDate": { "year": 2022, "month": 7, "day": 17 },
        "lastDate": { "year": 2022, "month": 8, "day": 13 }
      }, {
        "firstDate": { "year": 2022, "month": 7, "day": 24 },
        "lastDate": { "year": 2022, "month": 8, "day": 20 }
      }, {
        "firstDate": { "year": 2022, "month": 7, "day": 31 },
        "lastDate": { "year": 2022, "month": 8, "day": 27 }
      }, {
        "firstDate": { "year": 2022, "month": 8, "day": 7 },
        "lastDate": { "year": 2022, "month": 9, "day": 3 }
      }, {
        "firstDate": { "year": 2022, "month": 8, "day": 14 },
        "lastDate": { "year": 2022, "month": 9, "day": 10 }
      }, {
        ...
      }
    ]
  }
}

المفتاح

تحدّد Key جميع السمات التي تعتبر هذا السجلّ فريدة.

{
  "formFactor": enum (FormFactor),

  // Union field url_pattern can be only one of the following:
  "origin": string,
  "url": string
  // End of list of possible types for union field url_pattern.
}

الحقول
formFactor	enum (FormFactor) شكل الجهاز هو فئة الجهاز التي استخدمها جميع المستخدمين للوصول إلى الموقع الإلكتروني لهذا السجلّ. وفي حال عدم تحديد شكل الجهاز، سيتم عرض البيانات المجمّعة على مستوى كل أشكال الأجهزة.
حقل الاتحاد url_pattern نمط عنوان URL هو عنوان URL الذي ينطبق عليه السجل. يمكن أن يكون الحقل "url_pattern" واحدًا فقط مما يلي:
origin	string يحدد Origin مصدر هذا السجلّ. ملاحظة: عند تحديد مصدر، يتم تجميع بيانات عمليات التحميل ضمن هذا المصدر في جميع الصفحات ضمن بيانات تجربة المستخدم على مستوى المصدر.
url	string يحدّد url عنوان URL محددًا لهذا السجلّ. ملاحظة: عند تحديد url، سيتم تجميع بيانات لعنوان URL المعني فقط.

المقاييس

metric هي مجموعة من بيانات تجربة المستخدم لمقياس واحد للأداء على الويب، مثل سرعة عرض أول محتوى مرئي. يتضمّن هذا الرسم البياني لمدرّج تكراري لملخّص استخدام Chrome في العالم الحقيقي كسلسلة من bins.

{
  "histogramTimeseries": [
    {
      object (Bin)
    }
  ],
  "percentilesTimeseries": {
    object (Percentiles)
  }
}

أو

"fractionTimeseries": {
  object (Fractions)
}

الحقول
histogramTimeseries[]	object (Bin) المدرّج التكراري للسلسلة الزمنية لتجارب المستخدم لمقياس معيّن. سيتضمّن المدرّج التكراري للسلسلة الزمنية سلة واحدة على الأقل وستصل كثافات كل السلال إلى 1 تقريبًا. وسيتم وضع علامة "NaN" على القيم غير المتوفّرة لفترة جمع البيانات المحدّدة.
percentilesTimeseries	object (Percentiles) الشرائح المئوية المفيدة الشائعة للمقياس. سيكون نوع قيمة النسب المئوية مماثلاً لأنواع القيم المحددة لسلال المدرج التكراري. وسيتم وضع علامة null على القيم غير المتوفّرة لفترة جمع البيانات المحدّدة.
fractionTimeseries	object (Fractions) يحتوي هذا الكائن على سلاسل زمنية لكسور مُصنَّفة، والتي يصل مجموعها إلى حوالى 1 لكل إدخال. يتم تقريب الكسور إلى 4 منازل عشرية. يتم التعبير عن الإدخالات المفقودة على أنها `"NaN"` في جميع الكسور.

صندوق

bin هو جزء منفصل من البيانات يمتد من البداية إلى النهاية، أو إذا لم يتم تحديد أي نهاية من البداية إلى ما لا نهاية موجبة.

يتم تحديد قيم البداية والنهاية في السلة حسب نوع قيمة المقياس الذي تمثله. على سبيل المثال، يتم قياس سرعة عرض أول محتوى مرئي بالمللي ثانية ويتم عرضه كوحدات منفصلة. وبالتالي، ستستخدم سلال المقاييس int32 أنواع البداية والنهاية الخاصة بها. ومع ذلك، يتم قياس متغيّرات التصميم التراكمية بكسور عشرية بدون وحدات ويتم عرضها كرقم عشري مرمّز كسلسلة، وبالتالي ستستخدم سلال المقاييس الخاصة بها سلاسل لنوع القيمة.

{
  "start": value,
  "end": value,
  "densities": [number, number, number...etc.]
}

الحقول
start	(integer | string) البداية هي بداية سلة البيانات.
end	(integer | string) النهاية هي نهاية سلة البيانات. إذا لم تتم تعبئة النهاية، هذا يعني أنّ السلة ليس لها نهاية وتكون صالحة من البداية إلى +inf.
densities	array[number] سلسلة زمنية لنسبة المستخدمين الذين لاحظوا قيمة هذه السلة للمقياس المحدّد. يتم تقريب الكثافات إلى 4 منازل عشرية.

الشرائح المئوية

يحتوي Percentiles على قيم اصطناعية لمقياس بنسبة مئوية إحصائية معينة. وتُستخدم هذه القيم لتقدير قيمة المقياس وفقًا لنسبة المستخدِمين من إجمالي عدد المستخدِمين.

{
  "P75": value
}

الحقول
p75s	array[(integer | string)] شهدت السلاسل الزمنية للقيم التي يحمِّلها% 75 من الصفحات المقياس المحدَّد عند هذه القيمة أو أقل منها.

الكسور

يحتوي Fractions على سلاسل زمنية لكسور مُصنَّفة يصل مجموعها إلى حوالى 1، لكل إدخال. تصف كل تصنيف تحميل صفحة بطريقة ما، وبالتالي يمكن اعتبار المقاييس الممثلة بهذه الطريقة على أنها تنتج قيمًا مميزة بدلاً من قيم رقمية، وتعبر الكسور عن عدد المرات التي تم فيها قياس قيمة مميزة معينة.

{
  "label_1": { "fractions": array[fraction]},
  "label_1": { "fractions": array[fraction]},
  ...
  "label_n": { "fractions": array[fraction]}
}

على غرار قيم الكثافة في سلال المدرّجات التكرارية، يكون كل fraction رقمًا 0.0 <= value <= 1.0 ويصل مجموعه إلى 1.0 تقريبًا. عندما لا يكون المقياس متاحًا لفترة جمع محددة، سيكون الإدخال المتجاوب هو "NaN" في جميع مصفوفات الكسور.

الحقول
p75s	array[(integer | string)] شهدت السلاسل الزمنية للقيم التي يحمِّلها% 75 من الصفحات المقياس المحدَّد عند هذه القيمة أو أقل منها.

UrlNormalization

عنصر يمثّل إجراءات التسوية التي تم اتخاذها لتسوية عنوان URL من أجل تحقيق فرصة أعلى للبحث الناجح. هذه هي التغييرات المبرمَجة البسيطة التي يتم إجراؤها عند البحث عن url_pattern المقدّم. لا يتم التعامل مع الإجراءات المعقدة مثل متابعة عمليات إعادة التوجيه.

{
  "originalUrl": string,
  "normalizedUrl": string
}

الحقول
originalUrl	string عنوان URL الأصلي المطلوب قبل أي إجراءات تسوية.
normalizedUrl	string عنوان URL بعد أي إجراءات تسوية. هذا عنوان URL صالح لتجربة المستخدم يمكن البحث عنها بشكل معقول.

حدود المعدل

تتشارك واجهة برمجة التطبيقات CrUX History API الحدّ نفسه مع CrUX API لإجراء 150 طلب بحث في الدقيقة لكل مشروع على Google Cloud لأي من واجهات برمجة التطبيقات التي يتم تقديمها بدون رسوم. ويمكن الاطّلاع على هذا الحد وعلى استخدامك الحالي في Google Cloud Console. ويجب أن تكون هذه الحصة الكبيرة كافية للغالبية العظمى من حالات الاستخدام ولا يمكن الدفع مقابل حصة أكبر.