HighFlyer

Your analytics dashboard says you had 8,140 visitors last month. Your sales pipeline says nothing changed. One of them is lying to you.

We see this pattern on a lot of NZ business websites. The numbers go up and to the right. The actual conversations don't.

The usual culprit is bots. Search engines indexing your pages. Security scanners poking at your forms. SEO tools doing competitor research for someone else. They all show up in your dashboard as "visits".

Most analytics dashboards we audit are counting between 25% and 50% bot traffic. Sometimes worse. If your numbers feel disconnected from your actual sales pipeline, that's usually why.

The 8,140 visits above? After we filtered out the bots, the real number was 5,275. A third of what the dashboard reported was crawlers, scanners, and scrapers.

Filtering them out is harder than it sounds. The naive fix is to filter at the server, blocking known bot signatures before the page is served. That works for a while. Then it stops, because most modern websites are served from a fast cache layer that doesn't always ask your server who's visiting.

The fix we now bake into every SiteFlow site is to put the bot check inside the visitor's browser. Real people run the check just by loading the page. Most bots skip that step. Anything that doesn't complete the check gets tagged as "probably a bot" and stripped out of the numbers you act on.

Not great for the slide deck. Much better for the decisions you make with the data.

This is why our SiteFlow web service includes analytics and SEO setup, not just design and code. The dashboard you check every month should be telling you the truth.

When was the last time you cross-referenced your website analytics with your actual sales pipeline?

Every morning the inventory job died. Someone restarted it. Same story the next morning. Eventually it stopped restarting at all.

This is the third time we've watched the same pattern in the last six months. An automated job, pushing stock to Shopify, syncing orders from WooCommerce, dispatching scheduled customer deliveries, runs for hours and times out. Someone bumps the time limit. It works for a week. Then it breaks again. Bumped again. Works. Breaks.

The instinct is to keep raising the timeout. The instinct is wrong.

In the Shopify case, an inventory sync was meant to run every hour. The store had about 7,300 items. The old approach was making roughly 14,600 individual requests with a one-second pause between each. The arithmetic alone put it over two hours. No timeout was ever going to fit.

We rebuilt it to send updates in batches of 250 instead of one-by-one. Same store, same data:
- Before: 14,600 calls, 3+ hours, timed out
- After: ~30 calls, 11 seconds, done

The same shape of problem hit a WooCommerce sync earlier this year and an auto-delivery automation for an NZ food manufacturer more recently. Different code, same root cause: a job designed for ten orders running against ten thousand. The fix is never "make the timeout bigger." It's "stop doing ten thousand things one at a time."

If you have a scheduled job that needs babying, restarted, retried, given more time every few months, the timeout isn't the problem. The shape of the work is.

Full write-up of the Shopify rebuild including the retry logic: https://highflyerglobal.com/blog/2026/04/29/erpnext-shopify-inventory-sync-graphql-rewrite/

What's a job in your business that someone has to "go and kick" once a week?

A customer running a brand selling into Europe and Asia asked us to add language support to their site. They thought it was a translation job. It wasn't.

If your site reads in Korean but the date format is American, the address line says "State" when nobody in that country uses one, and the price is listed in NZD because you forgot the converter, the language doesn't save you. A reader in Seoul is still going to bounce.

What the customer actually needed was English, Dutch, and Korean, with each market seeing the things that signal "this site was built for me." Local date format. Local currency. Address fields that match how people actually live. A language switcher that doesn't reload the whole page and lose the visitor's place.

We built the site so the language switches inline, instantly, with the visitor staying exactly where they were. The translations were the easy part. Getting every other detail right. That was where the work lived.

If your business sells outside New Zealand and your site is "translated", you're probably losing visitors who think it isn't really for them. They won't tell you. They'll just leave.

What's the smallest signal a website gives you that it wasn't built with your country in mind?