Perfect, that is all great information that gives me a better picture of what you’re looking for—thanks for putting that together. Since I don’t have the read-only link, I’ll just do my best to explain the issue but feel free to generate that and send it over as well if you’d like a walkthrough instead.
To get this working more like you’re expecting (in terms of the scroll animation) you’ll want to make sure the target for the interaction itself is the “track” that the fixed element scrolls within—not the Lottie element. This will base the animation timeline off of the height you set on that track element.
The reason you’re seeing it “jump” to 50% is because the element fully in view (where it sits at the top filling 100% of the screen height) is actually halfway through the “While scrolling in view” interaction. You can imagine 0% is right before it enters, 50% is in the middle of the screen, and 100% is right when it exits. You started exploring offsets at the end of your recording, but along with dragging the nodes in the interaction itself (where it starts and ends) the offset can be used to ensure the animation always starts and finishes where it needs to.
To get the animation to play up to 32% on page load (the point right before the box opens up), you’ll want to make a separate interaction that fires “When the page finishes loading” that plays the animation up until that point. Now you can edit your “While scrolling into view” interaction so the start point of the Lottie animation in the timeline is 32% of the total animation duration with an ending of 100%.
Keep in mind that if a user scrolls before the animation finishes initially or they refresh below the fold there may be some unexpected behavior (like the animation abruptly jumping ahead) but I think it will get you much closer to the effect you’re looking for.
Let me know if you end up generating that read-only link and I’d be happy to record an explanation in the project itself 