-
Notifications
You must be signed in to change notification settings - Fork 137
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
Issue/10784 blaze analytics part ii #10820
Conversation
Generated by 🚫 Danger |
📲 You can test the changes from this Pull Request in WooCommerce Android by scanning the QR code below to install the corresponding build.
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## trunk #10820 +/- ##
=========================================
Coverage 41.27% 41.27%
- Complexity 5085 5086 +1
=========================================
Files 1034 1034
Lines 59565 59632 +67
Branches 7991 7996 +5
=========================================
+ Hits 24585 24614 +29
- Misses 32792 32830 +38
Partials 2188 2188 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work @JorgeMucientes, all of the events work well, I left two comments, but none is blocking, we can address them if needed on separate PRs.
@@ -128,6 +140,12 @@ class BlazeCampaignBudgetViewModel @Inject constructor( | |||
) | |||
} | |||
fetchAdForecast() | |||
analyticsTrackerWrapper.track( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This gets called every time the duration slider is moved, which seems like a bug to me, I started a discussion about it here p1708002828270189-slack-C03L1NF1EA3
@@ -64,6 +67,7 @@ class BlazeCampaignCreationAdDestinationViewModel @Inject constructor( | |||
} | |||
|
|||
fun onDestinationUrlChanged(destinationUrl: String) { | |||
analyticsTrackerWrapper.track(stat = BLAZE_CREATION_EDIT_DESTINATION_SAVE_TAPPED) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a small difference between iOS and Android here, and I think we might need to have different events because of it, in iOS the Save
button is for the whole screen, and saves both the targetUrl and the parameters, while here this gets called when the targetUrl is changed, and not the parameters, WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, @hichamboushaba. I actually had thoughts of initiating a discussion precisely about this here p1707952047198469-slack-C03L1NF1EA3 😅. However, I refrained from it because I didn't think the difference was that relevant. But after reading your comment I guess I should reconsider it :)
I agree we should have different events here as the frequency in which the save button is clicked will likely be very different between platforms.
Wdyt about a new event for Android: blaze_creation_destination_url_changed
replacing the actual blaze_creation_edit_destination_save_tapped
, and leaving the latter only on iOS?
If agreed, I can proceed and update the P2 with this slight difference between platforms
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wdyt about a new event for Android: blaze_creation_destination_url_changed replacing the actual blaze_creation_edit_destination_save_tapped, and leaving the latter only on iOS?
Sounds good, will you add one other event for the URL parameters?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind. Is a really minor change, but do you think we need that level of detail? Are we going to use that event?
Nah, let's add it just in case; it won't harm. Although I have doubts about how useful it will be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO this is the part that most users will use, the majority will be happy about the product URL as destination, so they probably won't change.
On another note, just an idea, if we want to keep the same event as iOS, we can probably just fire it when the user taps back on the screen, we can check if the data has changed, and if yes, we consider it as a save button call, it's a minor point, just wanted to share it, feel free to ignore it though if you already added the new events.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah good point, I like that idea better, especially because it keeps event parity between platforms. Applied it here: 5a9474c
# Conflicts: # WooCommerce/src/main/kotlin/com/woocommerce/android/ui/blaze/creation/ad/BlazeCampaignCreationEditAdViewModel.kt # WooCommerce/src/main/kotlin/com/woocommerce/android/ui/blaze/creation/payment/BlazeCampaignPaymentSummaryViewModel.kt # WooCommerce/src/main/kotlin/com/woocommerce/android/ui/blaze/creation/preview/BlazeCampaignCreationPreviewViewModel.kt
@@ -219,11 +223,13 @@ class BlazeCampaignBudgetViewModel @Inject constructor( | |||
val dailySpending: String, | |||
val forecast: ForecastUi, | |||
val durationInDays: Int, | |||
val sliderDurationValue: Float, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know @JorgeMucientes you are still working on this, just wondering, do we need an additional property in the State for this, when I was planning to work on this I was think we can just make this a UI detail, and handle it using Compose's functions, so we'll just initialize a State using rememberSaveable
in the BottomSheet to keep the state of the duration slider, then when apply
is clicked, we pass this State's value as a callback to our ViewModel, WDYT?
In addition this change adds a repository cache for ai ad suggestions to avoid requesting suggestions twice when entering edit ad screen
Hey @hichamboushaba, the PR is ready for another round. Thanks for all the provided feedback 👍🏼. Here's a summary of the changes applied:
Sorry for the many changes added, but I think applying them in this PR made sense because that enabled firing the tracking events at the right time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work @JorgeMucientes 👏, thanks for addressing those issues and the new ones.
I left some np comments, but please check the first one before merging.
import kotlin.math.roundToInt | ||
import kotlin.time.Duration.Companion.days | ||
|
||
@Singleton |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
np, Do we need to make this @Singleton
for this? this will cause the data to be cached for the whole lifetime of the app, and if someone forgets to pass forceRefresh
, we could be reusing wrong suggestions.
WDYT about saving the suggestions in the Preview ViewModel, and pass them as an argument to Edit Ad ViewModel?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, the reason I went for this approach initially is because it was easier and required a bit less file changes. But its true that it has that risk. So I used nav args instead and completely removed the repository cache.
Good suggestion 👍🏼
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @JorgeMucientes, and sorry for nitpicking on this.
One point just for context, no need to change unless you agree with me, I suggested caching the suggestion at the ViewModel level, and not the CampaignDetails
, because adding them as a parameter to the CampaignDetails
will cause them to be saved to the SavedState, while we don't need it really, as they can be re-fetched if the screen ViewModel gets re-created.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. I've extracted it out of the CampaignDetails
model to a class field 👍🏼
} | ||
} | ||
|
||
private fun calculateDailySpending(duration: Int): Float { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice find, thanks for fixing this.
return if (dailySpend < CAMPAIGN_MINIMUM_DAILY_SPEND) { | ||
CAMPAIGN_MINIMUM_DAILY_SPEND | ||
} else if (dailySpend > CAMPAIGN_MAXIMUM_DAILY_SPEND) { | ||
CAMPAIGN_MAXIMUM_DAILY_SPEND | ||
} else { | ||
dailySpend | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
np, we can simplify this logic using coerceIn
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Way simpler TIL
# Conflicts: # WooCommerce/src/main/kotlin/com/woocommerce/android/ui/blaze/BlazeRepository.kt # WooCommerce/src/main/kotlin/com/woocommerce/android/ui/blaze/creation/destination/BlazeCampaignCreationAdDestinationViewModel.kt # WooCommerce/src/main/kotlin/com/woocommerce/android/ui/blaze/creation/payment/BlazeCampaignPaymentSummaryViewModel.kt
Part of: #10784
Description
Ads tracking for all the new events for Blaze campaign creation native flow
Testing instructions
🔵 Tracked: event_name, Properties: property_name:value ...
to ensure all of the events from the table are fired appropriately.Note: the last 2 events from the table
_blaze_campaign_creation_success
and_blaze_campaign_creation_failed
are not included in this PR as the code for firing the campaign creation and handling the success/error result is not ready yet