April was fairly efficient. We made a lot of changes and additions to the functionalities, and fixed a huge number of different bugs.
We added icons to buttons.
We introduced additional domains for tracking.
We made enough functional Update costs (traffic costs update):
We updated devices databases; I redid my landers right away, and as a result, ROI increased over 2x in a single sweep. We improved mobile-detect extremely, and it detects desktops perfectly. Any problems with desktop detection because of browscap are solved. Device type works smoothly, in the next update, we will do redirect by it.
Now examples
List of changes
– Documentation
– New system of device definition (it improves detect by times)
– Multi-domains
– New installer
– Buttons icons
– Statistic by days in camping reports
– Update costs: selection Costs/CPC
– Update costs: Time zones
– Update costs: Import from CSV
– Update costs: automatic adjustment of current timeframe of a report
– PHP error handler (we will be able to check your mistakes without long investigations)
– Name randomization CSV files
– Notification of exit from campaign editing without saving
– Temp_report –> MyISAM
– Internal procedures optimization, reducing by 2x the database accesses
– Divided custom timeframe in date and time
– Redirect by IP ranges (both recording forms)
– Default grouping in reports: Path-Offer-Lander
– Deleted column Language on a landing page, instead of it language is written in gray to the right form the landing’s name
– Combined Chromium and Chrome in reports by browsers
– Browser version cut to 2 numbers by deleting Chrome’s odd zeros.
– OS versions cutting to two numbers
– Defaulted values of Token’s name (t1,t2..) in fill-in-the-blank field in a source
– Took away autocompletion in tokens in source editing
– Tokens {clickid} and {campaignkey} on landers
– Possibility to direct traffic to defined path or LP (&to_path=1&to_lander=2)
– We changed the cloning processing of offers, landers etc. Now it works without glitches.
– Apply button
– Redirect by user-agent by entry
– New update system
– Checking of input value during conversion update
– Statistic by Rules in reports by paths
Regarding development. In next update we will try to create leads in reports, upsells (cost adding to conversion, for subscription, goods, etc.). We are gradually developing the API and the 1-click installer through SSH for fast set up based on droplets etc.
The only thing we need to rewrite is payment panel for discounts by multi-licensing.
In general, we are planning to slow down development of new functionalities to normalize current one (bugs, bugs, bugs).
I tested responsiveness on DigitalOcean. It is not that bad. Average respond on a dedicated server is 30 ms, and on 4 GB DO it is about 50 ms with decreasing trend during replenishment of internal agent database. 2 GB memory is not enough, but works normally. If the volume is not that big, it can handle it, but response times will be slower to 80-100ms. So, I advise increasing RAM to 4 GB.
Most of the time required for a click processing takes place at the server’s databases; this is the only thing we can’t influence. We spent 80-90 percent of our time on that. But, in the next update, we will be downloading to our tester’s base the top agents (by detect quantity) during update and installation. This way response times will be decreased by 2x. We are fighting for each millisecond!
We updated the tracker with an error reporting system and other issues monitoring. Soon we will add a permanent response check-mark to check if something has gone wrong. These problems (with response time increase) is something all trackers have. You never know where or what component are having an issue and nobody pays attention to it. And how wrong that is! This key element directly influences your ROI.