I just kept refreshing. 1-2 minutes.
3 Likes
Thanks for confirming.
Do you (or anyone) know if MDE displays a time at any point in the G+ booking process after the initial click?
My hunch is that MDE locks the time after the initial click too, but if it doesn’t tell you what it is until after you complete the booking, it’s not much use.
3 Likes
The flow is…
- Tipboard Screen – You see a time you like and click it
- Guests Screen – You select the people that are eligible, click continue
- Offer Screen – The app sends the attraction you want and guests you want. You are shown an offer for the time that is available “now” (could be different from TipBoard click). It is yours if you want it at this point. Two paths… 1) You click continue and claim the offer, it’s assigned to you+guests 2) The offer expires in 10 minutes if you don’t click continue
- Confirmation Screen – Success! Shows the time window and guests.
4 Likes
Welcome!
Thanks for the info.
Question - have you tested that the offered return time expires after 10 minutes?
3 Likes
Len mentioned it in the podcast several months ago; I believe that’s why you often see a bounce in times shortly after the 07:00 rush. Within the past week I don’t see data to prove out exactly the “10 minute” rule, but maybe if you kind of squint real hard. For example on Slinky…
2022-07-08 – Bounced to 10:45 return time at 07:19
2022-07-09 – Bounced to 11:55 return time at 07:10
2022-07-10 – Bounced to 10:25 return time at 07:08
2022-07-11 – No bounce
2022-07-12 – Bounced to 10:35 return time at 07:08
2022-07-13 – Bounced to 08:30 return time at 07:05, bounced to 10:10 return time at 07:06
2022-07-14 – Bounced to 11:20 return time at 07:02
All of these are “blink and you’ll miss 'em” offers. They disappear VERY quickly.
2 Likes
3 Likes
There was a reddit thread on this a while back but I was skeptical of it… I doubt there will be many people who balk at completing a G+ booking in significant numbers.
3 Likes
It was really bad earlier in the year when the crowds were insane (you’d see lots of bounces). I think of it as an ouroboros: a thundering herd makes MDE act poorly, people can’t complete it (either by frustration or not able to), the offer goes back in the pool, rinse-repeat.
2 Likes
I didn’t think people saw this with BG1? Do they?
2 Likes
Hmm, see what? I’m confused about your question (a common occurrence for me)
Also: is there a better thread for me to nerd out about data? Don’t want to clutter a thread that may be meant for park goers looking for help on the topic.
1 Like
Oh! Many of us love data too, so the usual answer is please add data anywhere you see it fitting!
My personal opinion is I would love you to post some of you observations here since there have been discussions regarding “drops vs what you call bounce”.
https://forum.touringplans.com/t/genie-ll-daily-drops/82151?u=principaltinker
I would also be interested a discussion of your view vs BG1 view?
https://forum.touringplans.com/t/new-genie-ll-guardians-bg1-link/86504?u=principaltinker
4 Likes
In Len’s post, a user asked if you’re looking for beta testers in the parks or at home?
I also clicked on the link you provided in your profile. The banner mentions that your app is free in July and August while in beta. What do you anticipate the cost of the app to be once testing is over?
3 Likes
The 10 minute offer expiration is pretty easy to verify with the API. A lot of that reddit post was speculation of varying levels of believability (I don’t think everyone’s app crashing right at 7 AM was the cause for the ~7:10 non-drop drop), but the 10 minute expiration is fact unless someone else has done more recent testing to prove otherwise.
6 Likes
In my experience the bouncing of times is an ILL problem, not a regular Genie+ problem.
5 Likes
Dumbest of questions…did you get this screenshot on your phone? Where do I go to find this screen?
2 Likes
Example… For Slinky, between 08:05 and 08:15 on 2022-07-15 the prevailing offer was either 19:10 or 19:15. But at 08:10 the TipBoard was offering a return time of 12:00. It went away very quickly.
Based on the (frequently ephemeral) data the TipBoard is very clearly bouncing between multiple back-ends – which seems obvious from a system of this size. Part of my guess is based on some of the API calls previously available in Postman – has since gone private. Some of the calls referenced ‘global-pool-A, global-pool-B’, etc.
If I had to build something like this I’d have the backend (the fastpass system, literally https://fastpass.wdprapps.disney.com; crt.sh link) send the latest inventory option to an event processing service, then the TipBoard service (Vas) would pull in the data and store it in DBaaS (E.g. redis) for distribution to the users. Lightweight, real-time synchronization not necessary and gives the users what is the most plausible prevailing offer. If one Vas node has a problem pulling from the events (or is restarting, or is overloaded, or is an old node coming back online, etc etc) then you’d see the bouncing behavior.
My opinion is that the TipBoard is apocryphal. BUT, they could be legitimate offers that are just being scooped up by people very quickly. Hard to tell without more hard data (a bounce confirmed booked by a guest).
2 Likes
I booked a number of what you describe as bounces on my trip a few weeks ago with lots of refreshing. I think these bounces (as opposed to drops) are cancellations that are returned to the pool.
3 Likes
Check a pinned thread in the La Cava category
3 Likes
It is the BG1 screen.
4 Likes