Inventory the data source and existing senders
An integration plan should record the domain, Meta business portfolio, data source identifier and change owner together. Decide whether to use an existing source before creating another one. Replacing it without understanding campaign and reporting connections can complicate diagnosis. Arrange task-appropriate access while keeping ownership under the merchant’s control.
Inspect native settings, theme code, Script Management and GTM for existing Meta senders. Record which events each source produces and whether it remains necessary. An access token is confidential; do not put it into public documentation or support screenshots. Evaluate domain verification requirements against the relevant Meta feature rather than applying one historical iOS checklist to every implementation. A starting configuration and recovery path help distinguish a new defect from a pre-existing measurement gap.
Use the native identifier field without duplicating code
For tracking setup, Ticimax’s official Pixel instructions identify Settings > General Settings > Digital Marketing and Facebook Settings. The Facebook Pixel ID field receives the identifier. The guide says not to paste the complete base code separately into the site. If your panel differs, confirm the corresponding current function with support.
Compare the identifier with the intended store and source before saving. Manual code may be evaluated for a documented custom requirement; adding a second sender beside native integration is not the default remedy. Observe which events the current theme and payment journey produce. A populated field does not prove correct Purchase values, variant matching or every payment method. Acceptance evidence must include behavior beyond the settings screen, with the expected action and the observed record kept together.
FROM READING TO A NEXT STEP
Review Ticimax measurement
We can examine existing senders, user choices and shopping events to define a scope with clear owners and acceptance evidence.
Verify the selected CAPI mode and deduplication separately
Ticimax supports server-side measurement through its documented Facebook Access Token field. A separate official update note explains Facebook Pixel ID Olmadan Conversion API Kullan: it suppresses front-end Pixel code and selects server-only delivery. In that mode, an absent browser Pixel does not by itself establish complete integration failure.
The technical owner should approve the mode and payload. When browser and CAPI send the same action, Meta’s deduplication documentation recommends matching event names and identifiers: browser eventID corresponds to server event_id. Do not assume differently identified copies merge automatically. Ticimax’s CAPI guide also warns against adding event statuses again after setup. Server delivery does not remove permission requirements or recover every missing signal.
Test the business meaning of each shopping event
In event verification, distinguish PageView from product views, cart activity, checkout initiation and purchase. Does AddToCart represent a click or successful addition? Which order status produces Purchase? The developer and merchant should accept these definitions together rather than assuming identical behavior across themes. A familiar event name alone does not establish its correct trigger.
Compare controlled scenarios with the expected item, value and currency. Document discounts, shipping and tax treatment rather than inventing one universal store configuration. Inspect browser/server sources and diagnostics in Events Manager together. A processed status does not make incorrect information accurate. Include failed payments and reopening the order page alongside the ideal journey. Plan these checks in an authorized controlled environment; do not create a real customer purchase solely for diagnosis.
| Action | Question | Acceptance evidence |
|---|---|---|
| Product view | Does it identify the selected variant? | Selection agrees with the event identifier |
| Cart addition | Is successful addition represented? | Failure creates no unintended event |
| Checkout start | Does it represent the defined step? | Trigger point recorded for the chosen journey |
| Purchase | Are status, value and repeat visits correct? | Controlled order and expected event count |
Check preferences in both delivery paths
When planning data transfers, identify each field’s purpose and destination. A visible cookie notice does not prove delivery follows user choices. The relevant official KVKK decision summary distinguishes necessary cookies from other purposes and describes opt-in before processing where consent is required.
The responsible data owner should assess applicable processing and transfer conditions. Test the initial visit, acceptance, rejection and changed preferences against browser requests and server sending. Do not use CAPI to bypass a rejected advertising preference. Keep free-text order notes, payment information and sensitive health inferences out of payloads. Hashing does not make unnecessary data necessary. Handover should explain which fields are blocked, when permitted delivery operates and which boundaries still require review.
Verify catalog matching and separate marketplace outcomes
The product data quality checklist can connect catalog records with event identifiers. A Ticimax feed does not prove every variant matches or that availability updates instantly. Review scope, the last successful retrieval, errors and variant destinations separately. The product owner accepts commercial information; the developer verifies matching behavior.
Meta’s current catalog guidance describes content_ids or contents matching for ViewContent, AddToCart and Purchase. Check connections and failed identifiers against those definitions. A storefront Pixel does not automatically measure every action on a separate marketplace; inventory synchronization and advertising events are different flows. Combining Trendyol or Hepsiburada orders with storefront purchases under one source label can distort channel interpretation. For multiple brands or domains, evaluate documented source separation rather than considering a second pasted script sufficient.
Use one record for acceptance, handover and removal
The launch and change checklist should repeat scenarios after theme, payment or tag changes. Do not guarantee that native integration is unaffected by every theme change. Before removing older code, verify its owner and events; afterward inspect for gaps or duplicates. Deleting a Meta data source is not the default remedy for an incorrect storefront installation.
Current Meta documentation calls the former Pixel Helper Meta Ads Data Advisor. Browser diagnostics can help, but one green indication does not accept the complete server and preference journey. Review automated correction suggestions before they create another integration. Record environment, event, expected behavior, evidence, correction owner and retest date. This produces a handover the next operator can repeat without relying on an undocumented setup claim.
Missing or unexpected events
Inspect source, mode and action together. Distinguish behavior explained by preferences or server-only mode from a verified defect.
Duplicate counting
Compare native settings, theme code, Script Management and GTM. Identify the copy, remove it under controlled conditions and verify the expected count again.
Handover and recovery
Record configuration, ownership and recovery steps. Explain active sources and completed checks without sharing the confidential token.
BEFORE YOU DECIDE
Frequently asked questions
Where is the Pixel ID entered in Ticimax?
The official guide identifies Settings > General Settings > Digital Marketing and Facebook Settings. Enter the identifier. Separately pasting complete base code is not the native method described by that guide.
Is CAPI mandatory for every store?
Ticimax documents native support and a server-only option. Evaluate the mode against data needs and processing conditions. These documents establish neither universal necessity nor a guaranteed percentage improvement.
Does an absent browser Pixel mean setup is broken?
With server-only mode enabled, absent front-end code may be expected. Inspect mode, preference state and server records together; a browser extension alone cannot settle the question.
Do two sources mean two purchases?
Browser and server can report the same action. Inspect names, identifiers and deduplication. Differently identified copies or two browser installations should not be assumed to represent one accepted event automatically.
Should events be rechecked after a theme change?
Yes. Repeat product, cart, checkout, Purchase and preference scenarios against the same acceptance record. An identifier remaining in settings does not prove every changed page still behaves correctly.
Is clearing one field sufficient to remove setup?
Identify every active sender first. Native fields, tokens, theme scripts and GTM may be separate sources. Verify both paths after documented removal; do not delete unrelated analytics code or the data source without understanding its role.
LET’S DEFINE THE SCOPE
Review Ticimax measurement
We can examine existing senders, user choices and shopping events to define a scope with clear owners and acceptance evidence.
Review measurement