All of our ads work both on desktop and mobile but will be engaged with differently due to a check being made before it’s shown if the device uses a touch screen or not. If the device is without a touchscreen, arrows often appear over the ad to direct the user how to engage, otherwise, hand-icons will appear over the ad to direct the user how to engage with the format with their hands.
We do a massive job of always keeping all of our ad formats up-to-date by checking for changes in device and browsers updates as soon as they are released. Sometimes updates can interfere with the ad and fixes needs to be constructed and implemented asap.
A while back we got a notice about one of our ad formats not working “as usual” on a laptop, i.e. it not working to click/navigate with the computer mouse. When investigating we noticed that this only happened on laptops with touchscreens which is now a common thing.
What we noticed is that Google’s Touch Event API has three states disabled, automatic, enabled and on laptops with touchscreens it is always enabled. Which interfered with our own check before displaying an ad if the device uses a touchscreen or not.
This clash of checking device type and knowing what to register the ad as in a reporting system was a potential problem needed to be solved quickly to avoid faulty reporting.
The solution was simple, we removed our own check of device type before displaying the ad making it think it was a desktop ad every time. But since Google’s Touch Event API still was enabled for laptops with touchscreens we would get both results depending on engagement method. This made the ad work both ways and also report all events, both from touch and mouse click.
