FunnelFlux - Discount for STM Users (8)
UPDATE
We have now launched FunnelFlux Pro, our SaaS solution.
Check it out here, including your super awesome discounts - https://stmforum.com/forum/showthrea...-for-6-months)
Nice! Comes in handy right about now. 
Amy
Sent from my SM-G930W8 using STM Forums mobile app
Did you guys fix the clickid problem with cake yet?
Originally Posted by heavyt
It's not technically our problem, rather its poor handling of data on their end -- basically we use a 64-bit number for our hit IDs, so they are numbers of e.g. 17-18 digits. Javascript is limited to 53-bit integers, so if a system takes this value, treats it as an "integer" and then tries to render it with Javascript, it truncates it e.g. from 23471992547409923 to 23471992547409000.
This is poor handling by their system as they are taking a field that can have anything passed in it - text, numbers, symbols etc. and for some reason treating it as an integer rather than a string. Excel does the same irritating thing.
There is nothing we can do to fix this but you can easily test if your affiliate network suffers from the issue. Just pass a number with e.g. 18 digits under some tracking field and see if it appears as expected in your stats. If it gets modified or zeroes added then they are encountering this issue.
With Cake, we noticed the following:
- It doesn't happen with all networks (wtf, why Cake?). We have only had maybe 3-4 reports of this issue.
- It can affect the stats displayed and CSV exports but may not affect postbacks
- Their support is super helpful (/sarcasm) and asks for lots of details about the specific user, on what network, for what offer etc. instead of just passing the technical details to their development team
Not sure how bad is this issue (as you said you got only 3-4 reports), but if it's so difficult to communicate with CAKE and it could take ages to get the fix and then rolled out to networks wouldn't it be easier to "patch" it on FF side and use shortened hit IDs?
If even JS is limited to only 53 bits, I think it would make sense in the long-term as more issues could appear in the future.
I'm not using FF and it's not my problem, just giving my 2 cents on this.
We have a way to fix this, will look at implementing - basically will allow users to pass "flux_{hit-id}" to networks instead and then on our end will remove the flux_ we receive in a postback.
This way you get some letters/symbols passed in the data to the network so they shouldn't treat it as a number, which is the whole root of the problem - their system treating it as a number (more precisely an integer), and doing so badly from a coding perspective.
On our end we won't make any patching of hit IDs or similar, this would be fundamentally detrimental to the software. The hit IDs use 64 bit numbers because of substantial performance benefits -- the node-based tracking we do is a lot more demanding than other tracking systems and using 64 bit numbers allows for much faster queries, indexing, sorting, etc. at the database level.
I'd argue its good thatwe have encounterd this issue as it helps identify a coding flaw in these other systems that a lot of people use, which could cause severe problems for them later if they don't patch it themselves.
Thanks for shining some light on this.
I see now, having slower performance because Cake would be crazy.
The solution sounds nice and quite clean, hopefully it will work out for you!
Please let me know when the fix is implemented. I'm looking at switching from
Home > STM Treasure Chest >