Hello Kakao Pixel & SDK team,
We are integrating the Conversion API, following the Integration Guide v2.0. We have some questions about the event parameters (params) described in §2.5.5. Our observations come from test requests sent with debug: “Y” to our own test pixel (Track ID 8453444440824824339).
We asked the following questions on Kakao Customer Center, and they guided me to ask for help here
-
Is params required?
The guide does not say whether params is required for any event. In our tests, a Purchase event with no params at all returned 200 OK. Is params optional for every event code, including Purchase? Are any parameters required for an event to be counted as a conversion, or to be used for reporting or optimization? -
Must params follow the table in §2.5.5?
The table defines which parameters can be used with each event. However, Kakao also accepted parameters outside the table:
- A PageView event with search_string returned 200 OK, although search_string is listed for Search only.
- Unknown keys, both inside params (for example “coupon”: “SPRING”) and at the event level, also returned 200 OK.
Could you confirm:
- Are parameters outside the table ignored, stored, or used in any way?
- Should we strictly follow the table, and drop any parameter that does not apply to the event code before sending?
-
Why is currency added by default?
We see currency on events even when we did not send it. Is a default currency applied when currency is omitted? If so, what is the default value, and does it apply to every event code, including those for which the table does not list currency? -
Is there a recommended limit on events per request or on products per event?
The guide limits data to 1,000 events (§2.5.3) and states a 10-second timeout (§1.2). It does not mention any limit on the number of products per event, string lengths, or the total request size. In our tests:
┌────────────────────────────────┬───────────┬───────────────────────────────────────────────────────┐
│ Request │ Body size │ Result │
├────────────────────────────────┼───────────┼───────────────────────────────────────────────────────┤
│ 800 events × 10 products each │ ~1 MB │ 200 OK in 3.9 s │
├────────────────────────────────┼───────────┼───────────────────────────────────────────────────────┤
│ 800 events × 100 products each │ ~7.6 MB │ 200 OK in 24 s │
├────────────────────────────────┼───────────┼───────────────────────────────────────────────────────┤
│ 999 events × 100 products each │ ~9.4 MB │ the connection timed out after 37 s, with no response │
└────────────────────────────────┴───────────┴───────────────────────────────────────────────────────┘
Could you advise:
- Is there a maximum request body size, or a maximum number of products per event?
- What batch size and request size do you recommend so that a request completes within the 10-second timeout?
- When a large request times out like this, may some of its events already have been collected? §1.2 notes that a timed-out request may be partially processed, which matters to us because a resend would count those events twice.
Thank you for your help.
