CURRENT IMPLEMENTATION
Only eight dimensions enter the aggregate analytics table.
Each record contains the UTC day, event name, page path and sanitized `utm_source`, `utm_medium` and `utm_campaign` labels, plus a coarse traffic channel and predefined source bucket. A count and update time complete the row. Repeated matching events increment the same daily row. RFQ details do not enter this aggregate table.
RFQ SUBMISSIONS
Personal data is stored only when a visitor sends the form.
Email and WhatsApp links remain visitor-controlled alternatives. The site RFQ form is different: after the visitor checks the consent box and submits, the site creates an enquiry record and returns a reference number for follow-up.
- 01
Fields stored after consent
Company, work email, selected product family, optional reference model, requirement, quantity or project stage, target market, source page and allowlisted UTM source, medium and campaign labels.
- 02
Purpose
The record is used to review the request, identify missing selection details, respond to the buyer and follow the quotation or sample process. It is not added to an advertising profile.
- 03
Retention review
Each new RFQ receives a 12-month retention-review date. A record may be removed earlier on request or retained longer when an active quotation, order or legal-record need continues.
- 04
Abuse controls
The endpoint checks same-origin requests, payload size, required fields, a hidden anti-bot field and repeat submissions from the same submitted email. It does not store the visitor IP address.
WHAT IS MEASURED
Events that help improve sourcing paths.
- 01
Known crawler fetches
Successful public HTML requests whose User-Agent contains a fixed Google, Bing, Baidu, DuckDuckGo, Yandex, Apple, OpenAI, Perplexity or ByteDance crawler signature are counted in a separate daily table by date, page path, crawler bucket and whether the response delivered full HTML or a bodyless 304 Not Modified result. The complete User-Agent, If-Modified-Since value, request IP and URL query are not stored. A signature can be imitated, so this count does not prove crawler identity, indexing or ranking.
- 02
Traffic channel and source bucket
The browser reduces the landing referrer to a predefined search, AI, social, referral, direct, internal or campaign channel and a small known-source bucket. These sanitized labels and allowlisted campaign labels can remain in sessionStorage for the current browser tab so later product, resource and RFQ actions keep the same acquisition source. They contain no visitor or session ID and disappear when the tab closes. The complete referrer URL and search query are not sent or stored.
- 03
Page and product views
Aggregate counts by page path show which technical resources and product references receive attention.
- 04
Catalog search and technical calculations
The site counts completed catalog-search, pitch-calculation, AWG wire-size and terminal-block comparison actions but does not store search words, gauges, measured values or the models selected for comparison.
- 05
Resource downloads
Drawing PDF, product catalog, sample-approval checklist and RFQ workbook link clicks are counted by resource type and source page.
- 06
Contact intent
Email, WhatsApp, RFQ-email, cross-reference and stored-RFQ form entry clicks are counted against the source page. A click does not prove that a message was sent or a form was started.
- 07
Stored RFQ submissions
A successful site RFQ creates one aggregate rfq_submitted event by source page and allowlisted campaign labels. The enquiry fields remain in the separate RFQ table.
- 08
RFQ form funnel
The site counts a source-page RFQ form entry click, the first form interaction, a browser-validation block, a valid submit attempt and a failed submit response. These events do not include the destination model, field name, field value, validation message or enquiry content.
- 09
Related model clicks
A related-model click is counted against the source product page only. The target model, link text and individual browsing path are not stored.
WHAT IS NOT STORED
The analytics table excludes personal and message data.
- 01
No cookies, local-storage identifier, session identifier or advertising identifier.
- 02
The temporary sessionStorage record contains only sanitized acquisition labels—never a visitor ID, random token, timestamp, full referrer, search query or browsing history—and closes with the browser tab.
- 03
No IP address, complete referrer URL or HTTP Referrer header, browser User-Agent, device fingerprint or precise location stored in the analytics table.
- 04
No name, email address, phone number, company, message body, drawing content or uploaded file stored by the analytics endpoint. The separate RFQ endpoint stores only the fields a visitor knowingly submits.
- 05
No raw catalog search term and no arbitrary URL query parameter.
CONTACT LINKS
Email and WhatsApp remain visitor-controlled.
The website can open a prepared email or WhatsApp message with the current page and allowlisted campaign labels. The visitor reviews and sends it in the chosen application. YIHENTRA's website does not receive or store the message unless the visitor actually sends it through that provider.
The aggregate counter records only that a contact link was opened. Email and WhatsApp providers apply their own privacy terms after the visitor leaves this site.
DATA PURPOSE
Use aggregate evidence to improve product discovery.
Counts are used to compare pages, downloads and contact paths, diagnose failures and prioritize content. They are not used for advertising profiles.
LAST UPDATED
28 August 2026
This page describes the current website implementation and is not a substitute for jurisdiction-specific legal advice. If the implementation changes, this notice will be updated with it.