Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vdimitrakis/2960 evergreen campaign info fixes #98091

Merged
merged 4 commits into from
Jan 10, 2025

Conversation

therocket-gr
Copy link
Contributor

Related to

2960-gh-tumblr/a8c-dsp

Proposed Changes

we have some issues in the campaign details page for evergreen campaigns.

  1. the duration is not valid (we display 365 days instead of until stopped)

the before version looks like that (we show the start date and then the current day in the run between)

Screenshot 2025-01-08 at 5 58 27 PM

the after version should look like that

Screenshot 2025-01-08 at 5 57 38 PM
  1. we have an issue in the outperformed percentages (the calculation was wrong because we check total clicks and total impressions and then we calculate by getting the estimated numbers, but those are on a weekly basis)

example

Screenshot 2025-01-08 at 5 59 25 PM

the new logic will calculate (only for evergreen) the duration past in weeks and then it will divide the clicks and impressions by this number. the result should now be accurate (as we now compare weekly average clicks by the weekly estimated clicks)

  1. I noticed that we display orders even when the order is in pending state (so the user has not been charged yet and the order is not completed)

I added a condition to not display those orders

below is a ss with the buggy behaviour
Screenshot 2025-01-08 at 6 04 10 PM

Testing Instructions

some of the changes are hard to test

if you have an active evergreen and an active normal campaign get to the details page for each

  1. ensure the info in durations (duration part and run between) are ok
  2. ensure the orders are displaying ok
  3. ensure the outperformed values (for both campaigns) are somewhat expected

if you don't have active campaigns, you can create 2 (1 evergreen and one normal) and try to play with the variables

for example you can fake the total_clicks (hardcode them) change the campaign status from created (or scheduled to active) and so on to test different scenarios

most importantly do a thorough CR and check out that the logic in calculations seem ok

you re it

Pre-merge Checklist

  • Has the general commit checklist been followed? (PCYsg-hS-p2)
  • Have you written new tests for your changes?
  • Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
  • Have you checked for TypeScript, React or other console errors?
  • Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
  • Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
    • For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
  • For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

@therocket-gr therocket-gr requested a review from sbarbosa January 8, 2025 16:08
@matticbot matticbot added the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Jan 8, 2025
@therocket-gr therocket-gr requested a review from timur987 January 8, 2025 16:08
@matticbot
Copy link
Contributor

matticbot commented Jan 8, 2025

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~72 bytes added 📈 [gzipped])

name             parsed_size           gzip_size
promote-post-i2       +128 B  (+0.0%)      +72 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

Copy link
Contributor

@sbarbosa sbarbosa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

Copy link
Contributor

@timur987 timur987 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @therocket-gr!

Code LGTM and works as advertised.

@matticbot
Copy link
Contributor

This PR modifies the release build for the following Calypso Apps:

For info about this notification, see here: PCYsg-OT6-p2

  • blaze-dashboard
  • odyssey-stats

To test WordPress.com changes, run install-plugin.sh $pluginSlug vdimitrakis/2960-evergreen-campaign-info-fixes on your sandbox.

@therocket-gr therocket-gr merged commit 1435017 into trunk Jan 10, 2025
11 checks passed
@therocket-gr therocket-gr deleted the vdimitrakis/2960-evergreen-campaign-info-fixes branch January 10, 2025 11:47
@github-actions github-actions bot removed the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Jan 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants