sh-notion/notion_data_team_no_files/2024-07-26 - Glad you’re back, Pablo f40e0ea62143420d96b409f8f78e9fd9.md
Pablo Martin a256b48b01 pages
2025-07-11 16:15:17 +02:00

9.4 KiB
Raw Permalink Blame History

2024-07-26 - Glad youre back, Pablo

Things that happened when you were off that might require your attention

Xexe incident on July 18th

All details here: 20240718-01 - Xe.com data not retrieved

Revenue figures issues

Revenue figures are not fully consistent between Data (DWH) side and Finance. Xero-based reporting is generally ok, with some small discrepancies that have minimal impacts and can partially be explained. However, a massive discrepancy on Guest Revenue (Waivers, Deposit Fees, Guest Products) is detected since Data is reporting it with taxes included, while Finance seems to be reporting it without taxes. This generates discrepancies within Data reporting, in the sense that Xero-based reporting/metrics are usually tax exclusive. The issue is communicated on 24th July to all users

Data quality assessment: DWH vs. Finance revenue figures

Grand Welcome invoicing

GW is a franchise. They have 80 different accounts owned by their individual franchisees but they want them all to be billed as one.

On 15th July, it was discussed with Finance (Suzannah and Jamie), Clay, Leo and Uri. Main idea would be to have the invoicing export by deal id. Thus meaning, these 80 franchisees would be linked to a single Deal Id. This might have an impact on the invoicing reporting that I (Uri) am not really aware off, thus no estimation on impact/how much time will it take has been provided. Theres going to be a follow up on this subject by beginning August.

Some other subjects:

  • This is the famous account of the 9k duplicated bookings in March. In order to repay them for these problems, they have 2 free of charge months (thus gives us a bit of extra time). Note: the subject of duplicated listings was re-opened by Clay on Monday 22nd
  • Because of new pricing, they want to change from a listing-based charging type to a booking-based charging type. This is still another discussion that Leo/Clay need to have with the client, but of course this could impact the way its invoiced.
  • Potentially, it could be interesting to create somehow a “super user” that would be able to see the Dashboard for many “users” assigned to them. This was open discussion, not commitment.

eDeposit and Athena migration

Ana wrote to me the day you started holidays. Apparently, theres a CosmosDB migration that they wanted to do this sprint. In the refinement session it was discovered that this could impact the existing reporting we have on CosmosDB. Long story short, it seems the schema wont change and its just the URL that changes.

This might have an impact depending on how were retrieving the information on CosmosDB. We re-loop Ben R, and after discussion with Ray, seems ok to move forward since it would be a minimal impact on PBI reporting.

Pending update. Information available in #api-data channel.

Data Priorities check (15th July)

Only Suzannah and Uri were here on this edition. Topics discussed:

  • Finance top prios:
    • Minimum listing fees subject
    • Very important - Check in Hero will be rolled-out (offered) to all hosts that are interacting with Guests on Guest Journeys. Check in Hero will have a commission share with hosts, meaning that at the beginning of the new month, wed need to pay back part of the Check in Hero revenue. Suzannah to send an e-mail with the details (she did not send the e-mail, but Ben C actually asked me Uri and Ben R on feasibilities - I said that this will take quite a bit of time and effort)
  • KPIs / Business Overview
    • Wed need to do an exercise on revenue comparison between Business Overview and Finance reports. It seems there are some discrepancies. A potential explanation could be the currency exchange rates (for historical finance figures on guest payments vs. the ones reported now). See point 2 - Revenue figures :) :) :)
    • Suzannah noticed (and I noticed as well) that a snapshot made on day D of a previous day Z can display different data on day D+X on the same Z day. I guess theres some past update happening on the database that since were fully refreshing the KPIs is being missed. We need to investigate this. Partially investigated with revenues investigation
    • Provide a possibility to chart metrics in the Main KPIs dashboard (done).
    • They would like to see the Host split per Client type (1-10 listings, PMs 11-100 listings, Enterprise 100+ listings), Geography (mostly Country, to be discussed: if Im a host located in England, but I have a Listing in the US, which one should I consider? B2B or B2C?). This has been discussed in the KPIs sessions, the details and recording being here: https://www.notion.so/knowyourguest-superhog/Business-KPIs-Definition-III-TMT-session-24th-July-2024-1bd5435844ac432f9161b1ccf4c4d062
  • Other
    • We need to provide access to all Finance to the Account Report (done)

Product visibility - Data visibility

Product has been working on creating general guidelines to present roadmaps and initiatives to the different business teams. After checking with Ben, were also supposed to do it.

Now, since Data is a bit special, Lou A has helped on determining what should we apply and what not. In a nutshell:

  • We need to discuss with Ben and Suzannah on priorities again because (as you see in this list) a lot of things happened in just 2 weeks. With this we can adapt the roadmap
  • We should adapt each item in the roadmap, ideally filling a bit more the description. The description template could be useful for us as well.
  • Lou A showed me the resolution roadmap she has with bigger timelines / not fully specified over time. I think this is a nice way to say “hey guys, we will do these during Q3, but I dont commit to do this in a given week”. Might be interesting to apply a similar strategy for Data
  • Record a 2 minute video explaining how to interpretate the Data roadmap, but not the contents of it
  • Have a session with business teams, but open to everyone, explaining a bit more the details of what we aim to do in Q3 or in the future. This should be recorded. It can be just a matter of 15 min prez + questions

Billing automation

Within the new dashboard initiative, theres the goal to do an automatic billing. We did a first kickoff on the discovery phase with Product (Dagmara - leading initiative, Lou D), Finance (Suzannah, Nathan, Jamie) and Tech (Ben R., Gus). Dagmara will need support from Data side to ensure that we can list the different data points used, the current process and so on.

Dagmara has created a very nice summary with the steps that will follow: https://www.notion.so/knowyourguest-superhog/Discovery-Plan-New-Dashboard-V3-Automated-Billing-940eb16d61684a4b9d2fca1001a127ea

Theres also a slack channel #proj-automated-billing

Billable bookings

While working on billable bookings, I started taking a look at the data-invoicing-exporter project. Theres a couple of differences that we might need to discuss, specially on the fact that charges that happen when the verification starts now uses a different logic in the data-invoicing-exporter (guest user joined date) vs. DWH in booking_charge_events (guest used link date, the estimated start date).

All details here:

Data quality assessment: Billable Bookings

Booking source field

Based on a Joan request (and actually something that interested as well Lou D, and probably other people), weve developed a new Booking source field that has been propagated within DWH. Might be worth that you do a double check just to verify all is ok.

Data incoherence on guest choices

Based on a request from Lou A where they want to know how many guests choose no cover over other payment options presented to them. Using a query provided by Lawrence E:

**select** *,

**CASE** **WHEN** DisabledValidationOptions & 1 > 0 **THEN** 0 **ELSE** 1 **END** **AS** *"Fee(1)"*,

**CASE** **WHEN** DisabledValidationOptions & 2 > 0 **THEN** 0 **ELSE** 1 **END** **AS** *"Membership(2)"*,

**CASE** **WHEN** DisabledValidationOptions & 4 > 0 **THEN** 0 **ELSE** 1 **END** **AS** *"FeeWithDeposit(4)"*,

**CASE** **WHEN** DisabledValidationOptions & 8 > 0 **THEN** 0 **ELSE** 1 **END** **AS** *"Waiver(8)"*,

**CASE** **WHEN** DisabledValidationOptions & 16 > 0 **THEN** 0 **ELSE** 1 **END** **AS** *"NoCover(16)"*

**from** live.dbo.PaymentValidationSetToCurrency

We found that there are some cases were its not making sense between the offered choices, according to this data, and the chosen ones by the guests. We have already bring this data incoherence up with Lawrence and he is currently working on trying to find the problem and hopefully soon have a solution.

Screening API Report ready for deployment

We have the new report for Screening API ready to go as soon as it is needed

Link