If anyone would like to know how I decided to ultimately make this work,
I added a column ‘Random AD’ number variable to each user profile (a database field that takes up permanent space, which is inefficient and causes bloat - Adalo team, take note - it leads to lag!)
When the ad is finished (timer that counts down on the ad page) before it lets the user move on to the next page in the app, it "updates’ User with rand(1,advertisement max) in that Random AD field.
This works for the next ad display.
I decided to generate the number after the ad displays to prevent delay in serving the ads when the user lands on the page for the first time. Any delay at all in serving up the ad will make it look like your app is running slow. Even a fraction of a second of a blank screen makes it look like you’re buggy. Instead, add the fraction of a second to the back end since it’s a light update (simply changing a variable) and if it fails to update, they get the same ad twice in a row, not a huge deal. I am fine with that failing to update properly from time to time, and people seeing some ads in a row, than with having the ad fail to load.
It’s not about the amount of time the ad is seen.
It’s the perception on the user side - when you’re waiting to see a screen load once it has appeared, you notice how long it takes before something appears for your eyes to focus on.
Versus when an ad is displaying for several seconds and you don’t care, you’re waiting for the next thing - when the ad initially disappears is when your user then focuses on the screen again and at this stage, it takes them a second to realize something is even happening.
The reason I chose the ‘Max’ instead of ‘count’ is because as the Adalo database grows, it appears the system gets bogged down having to pull EVERY record and then count it. By selecting max (I do have a variable that is Ad ID that I’m pulling from), I can more efficiently find out what the max number is.
Again, you don’t notice these things in testing / in the first stages of building an app. These are variables that drag your database performance down over time as it gets more and more bloated.
I would much prefer the original method I had outlined. As soon as that’s an option, I’ll be shifting to that method and removing this less efficient method.
Initially, the hiccup is that the first ad they ever see in the app may be blank (I dont think anyone will mind). But after that, it will set the next random ad ID for the next time they see an advertisement.
Again, this is not efficient.
Adalo needs to get their RAND() function working properly as I had originally described it.
Random generated numbers should not need to be stored for every user in this way.
**Multiply this across hundreds, thousands of users, you’re putting twice as much stress on pulling/updating information which is twice the work load for your databases. **
I’m being forced to update a field on every page exit to make this work when I shouldn’t need to and then call that field when I come back to that page and display it.
**This is double the work on the database and servers. **
And you’re data heavy.
Take some of that funding money, Adalo, and get someone that understands this kinda stuff.
No amount of marketing is going to save you if you’re churning users left and right because of unreliable ‘basics’ and bad logic / bloated data / slower services.
I think Adalo has the funding to fix this entire mess. Now, simply a matter of deploying that capital efficiently / effectively in the right places. Adalo appears to be in the hire/fire stage and I hope that means you’re getting your house in order.
