MagicBand+ announced

[HauntedPirate]

Pure tech speculation here - and sorry for those who aren't up on database design - but a common pattern for very large tables is to partition the table on specific fields, so part of the table is stored in one file and part in another. If, let's say, the table was partitioned on magic Band status, moving a large number of bands to inactive would significantly shrink that partition and could significantly improve performance, without having to physically delete the records.

That being said, I don't see any reason Disney should invest in more storage to support a set of magic bands that are 99% unused and are over a decade old. If I were Disney I would announce the sunsetting of MB1 on a specific date. At that point, all those magic bands would be purged and unable to be reactivated without calling Disney support. Users who still have and want to use an MB1 could go to a page to click a button that keeps it active. That lets them clear out 99% of that data.

Personally, I think there should be a way for user's to permanently remove a MB from their inventory, with a pop-up window warning users and all that (I wouldn't trust Disney IT to do any sort of work around a mass MB disable without a debacle ensuing). I'm sure I have a dozen old AP cards and MBs that I could remove (I don't buy MagicBands, for the record) to help out the database size.

 

[AEfx]

The database should be extremely simple.

Serial Number. Style Number. Email address.

I can't think of anything else that would need to be included. All of the complexity is on the Disney ID side, not attached to the band itself.

Oh, I'd be willing to bet there is a lot more there, especially if they actually had the intention of doing what they originally said they would do with them that never came to fruition.

Example, you were supposed to be able to walk up to a NextGen Mickey, and he would know your name, and if it was your birthday, etc. In designing for something like this, it would have made much more sense to carry that data over to the MagicBand database itself, instead of having it hit the reservations system constantly to access that data. Both in terms of speed and database load on the reservations system.

It also has the unlock codes for the rooms they are authorized for, as well as the admissions media attached to that user - or you'd be waiting with a delay like swiping a credit card transaction every time you used it, instead of the nearly instantaneous way they work now. It may not sound like a big difference, but when opening your room door or using it to enter a park, a second or two versus even 7-10 seconds really adds up (both for the user and overall operational efficiency).

I'm pretty sure we would find that instead of just a simple link to your Disney profile, there is quite a bit of data copied over to the MagicBand database, which might be redundant at first blush, but operationally makes the whole system (and what it was intended to do) much more efficient.

 

[CaptainAmerica]

Oh, I'd be willing to bet there is a lot more there, especially if they actually had the intention of doing what they originally said they would do with them that never came to fruition.

Example, you were supposed to be able to walk up to a NextGen Mickey, and he would know your name, and if it was your birthday, etc. In designing for something like this, it would have made much more sense to carry that data over to the MagicBand database itself, instead of having it hit the reservations system constantly to access that data. Both in terms of speed and database load on the reservations system.

It also has the unlock codes for the rooms they are authorized for, as well as the admissions media attached to that user - or you'd be waiting with a delay like swiping a credit card transaction every time you used it, instead of the nearly instantaneous way they work now. It may not sound like a big difference, but when opening your room door or using it to enter a park, a second or two versus even 7-10 seconds really adds up (both for the user and overall operational efficiency).

I'm pretty sure we would find that instead of just a simple link to your Disney profile, there is quite a bit of data copied over to the MagicBand database, which might be redundant at first blush, but operationally makes the whole system (and what it was intended to do) much more efficient.

Maybe I'm missing something then because weren't they adamant that no personally identifiable information whatsoever would be stored on the band?

In your room key example, I think it works in reverse of what you described. It's not the band knowing how to unlock the door, it's the door knowing which bands are allowed to unlock it.

 

[Brian]

Maybe I'm missing something then because weren't they adamant that no personally identifiable information whatsoever would be stored on the band?

In your room key example, I think it works in reverse of what you described. It's not the band knowing how to unlock the door, it's the door knowing which bands are allowed to unlock it.

That is correct. The bands have nothing "on them" except for a unique identifier which is used by the various touchpoints to query databases as to what the wearer has access to.

When it comes to hotel doors, when the guest's assigned room is ready, the lock receives the identifiers of all the guest's bands and cards which are permitted to access the room. The more bands one has active on their profile, the more likely it is that one or more will fail encoding to the lock, which is one of the reasons why MB 1s are being mass deactivated.

Other touchpoints, like LL and park entry, receive the unique identifier upon tap, query the databases to see if the proper entitlement(s) to enter are present, and return the approval/denial based on what the database says.

If someone were to "hack" a physical MagicBand and read its data, all they would find is a long string of characters that is useless to them without access to the databases themselves.

 

[flynnibus]

It also has the unlock codes for the rooms they are authorized for, as well as the admissions media attached to that user - or you'd be waiting with a delay like swiping a credit card transaction every time you used it, instead of the nearly instantaneous way they work now. It may not sound like a big difference, but when opening your room door or using it to enter a park, a second or two versus even 7-10 seconds really adds up (both for the user and overall operational efficiency).

You clearly don't know how this stuff actually works...

The bands are nothing but ID numbers, radios and the ability to do validation/encoding. They are essentially nothing more than a really big number assigned to you, with radio I/O attached so it can interact with NFC and RF devices. The far end is doing everything...

Which is why your magicband can open your room without ever visiting the desk...

 

[flynnibus]

The only way to shrink the database is to delete entries altogether and then optimize the tables. The optimization would be a huge undertaking, unless the database is very simple, with few columns per device. Simply deactivating MB's based on some arbitrary criteria won't make the database of devices any less monstrous. Sure, running a query would then produce fewer results but unless they are keeping separate databases for inactive vs. active devices and thus deactivating devices would move their entry from one DB to another, deactivating devices won't really do anything.

And there is a functional limit of (I believe) 20 active devices in your MDE account and then problems start.

There are other designs.. like tiered data stores. Plus the ability to basically partition records until they are needed. There is a ton you can do here..

But occam razor here... if you know you have 95% of the devices that will never be used again, it's just more efficient to retire them and deal with the exceptions than it is to keep building more support for them at expense.

 

[HauntedPirate]

There are other designs.. like tiered data stores. Plus the ability to basically partition records until they are needed. There is a ton you can do here..

But occam razor here... if you know you have 95% of the devices that will never be used again, it's just more efficient to retire them and deal with the exceptions than it is to keep building more support for them at expense.

Valid point. I don't even think you'd have to go as high as 95% inactive to make a pretty solid case to pull the trigger on retiring the unused devices. I still don't trust Disney IT to do the job correctly, without impact.

I'm still not buying a MagicBand. Or a DisneyBand. The fact that they fooled so many people into shelling out money for them in the first place should be a case study.

 

[AEfx]

Maybe I'm missing something then because weren't they adamant that no personally identifiable information whatsoever would be stored on the band?

On the band itself, no - it's just a numerical code.

But that code accesses a database specifically for those Magic Bands, containing the info that Magic Bands are meant (or were meant, depending on the data, i.e. birthdays and such) to be able to quickly access. They aren't hitting the reservations system directly every time they access data. Or there would be much longer delays between scanning and accessing the data they need immediately, and it would be millions more hits against the reservation system daily that would bog it down .

I believe you will find that's why occasionally Guest Services has had issues syncing them up when updates are made to the reservations database - especially at the beginning. Because updated data wasn't always transferring from the reservations database to the Magic Band database.

 

[AEfx]

You clearly don't know how this stuff actually works...

The bands are nothing but ID numbers, radios and the ability to do validation/encoding. They are essentially nothing more than a really big number assigned to you, with radio I/O attached so it can interact with NFC and RF devices. The far end is doing everything...

Which is why your magicband can open your room without ever visiting the desk...

I may very well be incorrect about the door opening procedure (I haven't paid on property prices since these things came out), but I never said any data was physically stored on the Magic Bands themselves. The point was, we are talking about a database that the Magic Bands access, which has a subset of the data the overall reservations system has. That's where glitches have happened in the past - the updates made to the reservation system by Guest Services, etc., copying the new data over to the database they directly access.

 

[flynnibus]

I may very well be incorrect about the door opening procedure (I haven't paid on property prices since these things came out), but I never said any data was physically stored on the Magic Bands themselves. The point was, we are talking about a database that the Magic Bands access, which has a subset of the data the overall reservations system has.

And that's where you are still wrong... 'that the magic bands access...' is non-sense. They don't access anything. They are a token that presents itself.. and the various systems you interact with then use that piece of data to cross reference an identity and entitlements for whatever is relevant for that application (a door system, a gate, etc).

Applications would be querying a magic band platform to resolve band identifiers to other logical units. Applications like POS systems, keycard systems, entertainment platforms, etc. We don't know how much of the applications they consolidated into a single one.. vs ensuring separate systems being able to SHARE with each other.. but it's not really significant to this discussion.

Statements like "It also has the unlock codes for the rooms they are authorized for" and "as well as the admissions media attached to that user" show a fundamental lack of comprehension of how such architectures work. Think of it as the band just being a temporary # given to you. The magic band system would be responsible for linking that temporary # to a logic customer entity. Each application would have it's own repository of what is relevant about your customer entity #. Like, you are allowed to open door 2355... while another platform may link that same customer # to a reservation... while another platform may link that customer # to a ticket entitlement. The point is... the systems all have a way to all link to the same logical 'customer' now.. where prior to Next Gen, everything was silos and it was much harder to cross reference things.

The magic bands are just a way to present an identifier that can be trusted.. and provide a means to map that identifier to a logical identity that is used commonly through the NextGen experience.

That mapping layer can have scaling and stale data challenges... where it's being tasked to cope with data that is basically worthless now because its accounting for data that will never be used. It's like cleaning out your attic after years...

It's also possible that the newer generation bands have additional validation or other features that are holding systems back by having to support both a new and old model.. so deprecating the legacy use cases can improve functionality, security, and reduce complexity/cost to keep moving things forward.

For a system of this size.. it's probably a mix of both.

 

[flynnibus]

But that code accesses a database specifically for those Magic Bands, containing the info that Magic Bands are meant (or were meant, depending on the data, i.e. birthdays and such) to be able to quickly access. They aren't hitting the reservations system directly every time they access data. Or there would be much longer delays between scanning and accessing the data they need immediately, and it would be millions more hits against the reservation system daily that would bog it down .

No - you're assuming they duplicated all this information into this 'magic band database' - there is no reason for such things. What you are really thinking about is there is some new master database of all things about a customer... that notion is independent of magic bands as a identity token. That is more about the modernization of their single platform.. and you don't really know how much was consolidated vs what simply stays within a particular realm and is simply SHARED to other realms for consolidated views.

Your issues about 'much longer delays' are solved with caching systems. Disney has millions of customers... but there are only so many thousands on property at any point in time. For instance for ride terminals, caching 75k ticket records after their first use to speed up queries is pretty trivial to avoid dealing with blocking in a live database.

Disney wouldn't consolidate everything into a single data model... instead you ensure many different platforms can interwork and share using common identifiers. So I don't mix a transactional history of everytime you scanned into a ride into the data store as your hotel reservation. Instead I ensure both systems use a common reference that can link your ride scan data to the same logical person who is holding a reservation. So when an application wants to see everything that logical person did.. that application can interact with those different systems and get data from multiple sources, but associated with the commonly shared identity.

Don't confuse Disney having a consolidated VIEW of a customer to mean the data is necessarily consolidated itself.

 

[DCBaker]

Disney says MagicBand+ now interacts with select theater shows:

https://disneyworld.disney.go.com/guest-services/magicband-plus/

 

[gerarar]

Integration with Festival of the Lion King happened back in June during the movie's 30th anniversary.

Experienced it a couple times recently and was pleasantly surprised with it. On par with the plentiful usage during Fantasmic!, imo.

It vibrates/pulses during the different animal noises in the beginning, flashes during the lightning in Be Prepared, and dances different colors during the finale.

 

[Disstevefan1]

Disney says MagicBand+ now interacts with select theater shows:

View attachment 821665

https://disneyworld.disney.go.com/guest-services/magicband-plus/

YaY?

 

[HauntedPirate]

Integration with Festival of the Lion King happened back in June during the movie's 30th anniversary.

Experienced it a couple times recently and was pleasantly surprised with it. On par with the plentiful usage during Fantasmic!, imo.

It vibrates/pulses during the different animal noises in the beginning, flashes during the lightning in Be Prepared, and dances different colors during the finale.

So it's just a distraction during shows. Fantasmic. I mean, fantastic.

I'm sorry, but these things are just d-u-m-b. Not even as a kid would I have wanted one.

 

[Fido Chuckwagon]

Disney says MagicBand+ now interacts with select theater shows:

View attachment 821665

https://disneyworld.disney.go.com/guest-services/magicband-plus/

Maybe I’m crazy, but haven’t they been doing this all along?

 

[DCBaker]

Maybe I’m crazy, but haven’t they been doing this all along?

They've added more theater shows in addition to the Festival of the Lion King. Here's the list of new additions from Scott:

 

[DisneyDreamer08]

I feel like it happened during Frozen in August

 

[ToTBellHop]

Wow! This changes everything!

 

[Touchdown]

There the most efficient way to get in, they are easily accessible and the little lights make me smile. Infinitely better then using your phone for everything like DLR.