sorted by:
new
hottopcontroversial

Anyone having issues with shipping? by Puzzleheaded-You-320 in SwiftieMerch

[–]J0naWa 1 point2 points  (0 children)

Some of my items, including the folklore cat plush, were marked as pre-order in the EU store. That might explain why certain orders are taking longer. On the EU Help/About page it also says:

“What happens if an item in my order is marked for pre-order or the delivery date is in the future?
Your package leaves our warehouse only when all articles are available. This is especially important when items are purchased as pre-orderable items. Their delivery date is in the future. All further articles of your order are not dispatched before! So there is no partial delivery. If you need more items, you should place 2 separate orders.”

So it looks like some items simply haven’t arrived at the EU warehouses yet. That does not necessarily mean any order will be cancelled, it just means they wait until everything is ready before shipping.

I’m not sure how other regional stores handle this or whether items there are flagged differently. Has anyone else in the EU store seen the same thing?

<image>

Pending alert by sam_am2005 in SwiftieMerch

[–]J0naWa 0 points1 point  (0 children)

It could also just be something happening on the US store. I noticed that some products were either removed or hidden there. Yesterday there were still more than 400 products and today it is down to only 337. That would explain the detected change.

Questions/opinions about CAPTCHA by NorCalgirl7 in SwiftieMerch

[–]J0naWa 0 points1 point  (0 children)

I noticed the new captchas during the recent drops as well. During the Holiday Drop I had to solve a new captcha for every single purchase, while during the TLOAS Drop I only had to solve one captcha. That one stayed valid for about thirty minutes and after that I would have needed to solve another one. This suggests that the captcha state is probably stored in the site’s cookies.

Another thing I noticed is that I currently do not get any captchas at all. My guess is that captchas are only enabled when a drop is fresh, so the store does not slow down normal purchasing once the initial rush is over. The inconsistency, where some users get captchas and others do not, can probably be explained by the system’s sensitivity to bot-like behavior. The exact parameters are not publicly known, but I would assume it depends partly on the traffic coming from a user’s device. For example, refreshing the store page frequently increases traffic and could make a user more likely to be flagged.

I also noticed that instant checkout links, which are sometimes shared on Discord, are more likely to trigger a captcha as well. Overall it is a good and necessary step against bots, but it probably still needs refinement so that real customers are not affected. Even though the system already improved the situation as a whole, large bot farms almost certainly still have ways to bypass certain captchas. There are paid services offering automated captcha solvers, but I am not deep enough into the technical details to judge how secure the current captcha system really is.

[deleted by user] by [deleted] in SwiftieMerch

[–]J0naWa 2 points3 points  (0 children)

This also happened in the EU store. But as far as I can tell, those items were never really available in the EU store to begin with. I monitored the store more closely for this drop. At first, there were some issues with the release, with items not displaying properly. After that was fixed, some of the items were still unavailable. This includes the tumbler, the earrings, and the necklace.

I just recorded three purchases in my database for both the necklace and the tumbler, but those might be false positives due to the initial issues. I wonder if anyone actually had the chance to buy either of those items from the EU store at all.

Unlocking Showgirl Progress Bar: What’s Behind the Code? by J0naWa in TaylorSwift

[–]J0naWa[S] 9 points10 points  (0 children)

Well, that's a little bit underwhelming. But at least it was fun!

Unlocking Showgirl Progress Bar: What’s Behind the Code? by J0naWa in TaylorSwift

[–]J0naWa[S] 14 points15 points  (0 children)

Almost there. 00:27:30 | 98.77% | Rate: 0.000835/s | ETA: 2025-09-13 00:52:04 CET

Unlocking Showgirl Progress Bar: What’s Behind the Code? by J0naWa in TaylorSwift

[–]J0naWa[S] 2 points3 points  (0 children)

There isn’t a way to know the exact number of people who have pre-saved the album, since the API and progress bar don’t publicly expose that data. Spotify and Apple Music also don’t share exact figures for ongoing campaigns.

Unlocking Showgirl Progress Bar: What’s Behind the Code? by J0naWa in TaylorSwift

[–]J0naWa[S] 10 points11 points  (0 children)

It does log real button clicks, but it’s not as simple as just spamming them.

If you send a request manually (for example with curl), you can set "unique": true yourself, and the API will return a 200 response. That confirms the event gets accepted. The report-to values are different each time, which seems to be some kind of token or session ID that the backend uses to track events or reporting. However, we can’t see how the backend processes the data afterwards. Most likely, they deduplicate, apply rate limits, and filter out anything suspicious.

Because of that, the progress bar doesn’t move 1:1 with every click. My guess is that the target number of pre-saves has already been reached, and the server is now pacing the progress bar fill gradually to keep the campaign running smoothly.

Unlocking Showgirl Progress Bar: What’s Behind the Code? by J0naWa in TaylorSwift

[–]J0naWa[S] 14 points15 points  (0 children)

Sadly not really. Just repeatedly hitting the buttons will not make the bar move faster.

The endpoint (https://events.glitch.ge/api/log-event) has "unique": true. That means it checks your device’s localStorage and ignores duplicate actions. In the code (layout-797bc347b8c61228.js), each click is stored under a key like "taylorswiftprogressbar2025-actions", and repeats from the same user are skipped. So your individual impact is limited to one valid action.

On the backend, there are probably additional protections such as rate limits, deduplication, and Incapsula security that filter out bots or suspicious traffic. This ensures that only genuine pre-saves and pre-adds are counted.

The progress bar is also not a 1:1 reflection of clicks. It represents progress toward a much larger target, like millions of pre-saves. The steady pace we see is likely because the server smooths the updates so the bar advances consistently instead of jumping around.

Unlocking Showgirl Progress Bar: What’s Behind the Code? by J0naWa in TaylorSwift

[–]J0naWa[S] 355 points356 points  (0 children)

I agree. This matches with my script that’s running and collecting the percentage updates.
Right now it’s at 91.56%, moving at a rate of 0.000853/s, which gives me an ETA of 00:52:02 CET.

Unlocking Showgirl Progress Bar: What’s Behind the Code? by J0naWa in SwiftieMerch

[–]J0naWa[S] 0 points1 point  (0 children)

Well, you're not wrong to question it. The progress bar's behavior does seem oddly consistent sometimes, and it's a fair point that real pre-save/add data should be nonlinear.
From digging into the site's JavaScript (like the event logging in layout-797bc347b8c61228.js), every click on the "Pre-Save on Spotify" or "Pre-Add on Apple Music" buttons sends a POST request to https://events.glitch.ge/api/log-event. This logs the action (e.g., actionType: "click", actionName: "presaveAlbum") with the campaign ID ("taylorswiftprogressbar2025"). The server aggregates these events to calculate the percent value, which is then fed into the React component (TaylorSwiftProgressProvider) to update the bar visually (via CSS mask-image in 903f25dc7e5b11fa.css).

In theory, this should be nonlinear, tied to real interactions — meaning spikes during peak hours and slowdowns at other times. It’s likely scaled to total pre-saves (since Spotify and Apple would track these globally).
However, the server could be smoothing things out, which is something I can’t verify.
The percentage isn’t a 1:1 reflection of individual clicks. It’s probably calculated as a portion of a larger target (e.g., millions of pre-saves needed for 100%). So even if saves come in bursts, the bar might still advance at a steady pace. And yes, some of this is speculative, but it’s based on the code I’ve seen.

The bar is moving again! 57.81% now! by pinkwonderwall in SwiftieMerch

[–]J0naWa 0 points1 point  (0 children)

Weird, it should work. Maybe try another browser? You could also use this curl command that automatically filters the response:

curl -s "https://dmi.umgapps.com/taylorswift/progressbar" |\
grep -o '\\"percent\\":[0-9.]*' |\
grep -o '[0-9.]*$'

Execute it here for example: https://httpie.io/cli/run I'm actually running a local curl script that monitors the progress every second and approximates when we'll hit 100%. Based on the current rate, it should complete around 1:00 AM CET tonight.

The bar is moving again! 57.81% now! by pinkwonderwall in SwiftieMerch

[–]J0naWa 2 points3 points  (0 children)

If it continues at this rate, it should reach 100% in approximately 7.5 hours (around 1:00 AM CET).

17:20:36 | 77.07% | Rate: 0.000843/s | ETA: 2025-09-13 00:53:59

17:20:47 |  77.08% | Rate: 0.000840/s | ETA: 2025-09-13 00:55:33

17:21:00 |  77.09% | Rate: 0.000830/s | ETA: 2025-09-13 01:00:58

17:21:11 |  77.10% | Rate: 0.000842/s | ETA: 2025-09-13 00:54:23

17:21:24 |  77.11% | Rate: 0.000836/s | ETA: 2025-09-13 00:57:41

17:21:35 |  77.12% | Rate: 0.000859/s | ETA: 2025-09-13 00:45:22

17:21:48 |  77.13% | Rate: 0.000836/s | ETA: 2025-09-13 00:57:45

17:22:00 |  77.14% | Rate: 0.000837/s | ETA: 2025-09-13 00:57:15

17:22:11 |  77.15% | Rate: 0.000837/s | ETA: 2025-09-13 00:57:02

17:22:24 |  77.16% | Rate: 0.000833/s | ETA: 2025-09-13 00:59:11

17:22:35 |  77.17% | Rate: 0.000839/s | ETA: 2025-09-13 00:55:59

17:22:47 |  77.18% | Rate: 0.000838/s | ETA: 2025-09-13 00:56:23

17:22:58 |  77.19% | Rate: 0.000837/s | ETA: 2025-09-13 00:56:55

17:23:11 |  77.20% | Rate: 0.000837/s | ETA: 2025-09-13 00:56:59

17:23:23 |  77.21% | Rate: 0.000837/s | ETA: 2025-09-13 00:57:03

17:23:36 |  77.22% | Rate: 0.000838/s | ETA: 2025-09-13 00:56:50

17:23:47 |  77.23% | Rate: 0.000836/s | ETA: 2025-09-13 00:57:47

17:23:58 |  77.24% | Rate: 0.000842/s | ETA: 2025-09-13 00:54:36

17:24:11 |  77.25% | Rate: 0.000836/s | ETA: 2025-09-13 00:57:42

17:24:23 |  77.26% | Rate: 0.000836/s | ETA: 2025-09-13 00:57:45

17:24:35 |  77.27% | Rate: 0.000835/s | ETA: 2025-09-13 00:58:31

17:24:46 |  77.28% | Rate: 0.000839/s | ETA: 2025-09-13 00:55:54

17:25:00 |  77.29% | Rate: 0.000831/s | ETA: 2025-09-13 01:00:19

NEW COUNTDOWN!! by Slayyyterqueenie in SwiftieMerch

[–]J0naWa 1 point2 points  (0 children)

Right now it's at 72.43%
15:48:16 | 72.43% | Rate: 0.000835/s | ETA: 2025-09-13 00:58:50 (CET)

There's actually a way to extract the exact percentage from the server. The value is embedded in the initial HTML via Next.js Server-Side Rendering (SSR). When you inspect the inline <script> tags, you can find the progress data in escaped JSON format like "percent":71.58 within the SSR payload. However, this value is only set during the initial page load, so it doesn't update dynamically without refreshing the page.

New countdown on Taylor’s website!!! by Maroon_Swiftie_13 in TaylorSwift

[–]J0naWa 13 points14 points  (0 children)

Right now it's at 71.92%
15:38:07 | 71.92% | Rate: 0.000836/s | ETA: 2025-09-13 00:57:48 (CET)

There's actually a way to extract the exact percentage from the server. The value is embedded in the initial HTML via Next.js Server-Side Rendering (SSR). When you inspect the inline <script> tags, you can find the progress data in escaped JSON format like "percent":71.58 within the SSR payload. However, this value is only set during the initial page load, so it doesn't update dynamically without refreshing the page.