Which trial did that customer start?

A buyer says the trial never started, or says they were charged on day one. Tonight, three proofs, in a console you administer. Name the trial that customer started: the subscription id, the customer id, and the trial end. If the subscription stored no trial, write that, including a null start and a null end, and do not invent a day count to fill the hole. Show a different subscription whose customer id is not this one. Show another account's list that does not contain this subscription. If any of the three needs the person who wired billing, you have not named the trial. You have a banner and a guess.

This is the trial on one subscription. It is not the status. Which status is that subscription in? is the status string. A subscription can be active while both trial fields are null, and trialing is a status, not a substitute for the timestamp. It is not the product. Which product did that price sell? is the product id and the unit amount on a price. A price can be right while no trial is stored. It is not the tax. Which tax did that invoice add? is a rate id and a percentage. A percentage is not a trial end. It is not the role an invite granted, and it is not the chunk a search returned. Those are different objects, and they are not this id.

None of what follows is a rate for this product, and none of it is legal advice. The fields below are one processor's current description of a subscription, and the two samples are the same object. The counts below that are a 2020 paper about another firm's experiment. A day count on an example is not a census of your buyers. A paper that multiplied its dollar figures by a constant cannot name the trial on the subscription you opened tonight. They do tell you which numbers people mix up when they try to sound precise about a trial they have not opened.

Stripe's subscription object sample and Stripe's create-subscription response print the same id, and both store no trial. The id is sub_1MowQVLkdIwHu7ixeRlqHVzs. 28 characters. customer is cus_Na6dX7aXxi11N4. 18 characters. status is active. trial_start is null. trial_end is null. livemode is false, so the object is an example, not a live trial on your account. created, start_date, and billing_cycle_anchor are all 1679609767. The item's current_period_start is the same integer. current_period_end is 1682288167. The difference is 2678400 seconds. 2678400 divided by 86400 is 31 exactly. 31 days is the billing period on the sample. It is not a trial, because both trial fields are null. The item was created at 1679609768, one second after the subscription. The plan was created at 1679609766, one second before it. A one-second gap is not 7 days, and it is not 31 days (Stripe, The Subscription object, and Create a subscription).

The create page's request does not send a trial, and the sample amount is not the amount in the prerequisites. The sample request sends a customer and items[0][price]. It does not send trial_end, trial_period_days, or trial_from_plan. The parameter list says trial_period_days is an integer that overwrites any trial on the plan, and that trial_end can be the string now or a timestamp at most two years from the billing cycle anchor. The response does not use either. now is 3 characters. It is not a timestamp, and it is not null. The plan's trial_period_days is null. The price id is price_1MowQULkdIwHu7ixraBm864M. 30 characters. unit_amount is 1000. The prerequisite on the same page creates a price with unit_amount 2000. 2000 is not 1000. Do not paste 2000 onto this subscription because both numbers appear on the create page. quantity is 1. latest_invoice is in_1MowQWLkdIwHu7ixuzkSPfKd. 27 characters. The product is prod_Na6dGcTsmU0I4R. 19 characters. The subscription item is si_Na6dzxczY5fwHx. 17 characters. The version header on the sample request is 2026-10-28.endive. 17 characters, the same length as the item id, and not the same string.

The same pages name limits the sample does not sit on. Each customer can have up to 500 active or scheduled subscriptions. 1 on quantity is not 500, and one sample subscription is not a count of the customer's subscriptions. You may pass up to 20 subscription items. total_count is 1. 1 is not 20. The description maximum is 500 characters. The sample description is null. Null is not 500, and 500 subscriptions is not a 500-character description. If the first invoice is not paid within 23 hours, an incomplete subscription becomes incomplete_expired. 23 times 3600 is 82800 seconds. 82800 is not 2678400. A 23-hour payment window is not a 31-day period, and neither of them is a trial the sample stored. Status names on the object page are eight: incomplete, incomplete_expired, trialing, active, past_due, canceled, unpaid, paused. The sample is active. active is 6 characters. trialing is 8. 6 is not 8. A status named trialing, which this sample does not have, would still not be a trial end. The end is a timestamp or null.

The study people reach for when they want a trial length is a different document, and its own tables do not agree on which count is the 7-day arm. Hema Yoganarasimhan, Ebrahim Barzegary, and Abhishek Pani report a field experiment at a SaaS firm. New users were assigned to 7, 14, or 30 days. Table 1 prints 51,040 observations in the 7-day column, 51,017 in the 14-day column, 235,667 in the 30-day column, and 337,724 in total. 51,040 plus 51,017 is 102,057. 102,057 plus 235,667 is 337,724. That addition matches. Subscriptions are 7,835, 7,635, 34,564, and 50,034. 7,835 plus 7,635 is 15,470. 15,470 plus 34,564 is 50,034. That addition matches too. The within-group rates they print are 15.36, 14.96, 14.67, and 14.81. 7,835 divided by 51,040, times 100, is 15.350705, which rounds half-up to 15.35. The cell prints 15.36. 7,635 divided by 51,017, times 100, is 14.965600, which rounds half-up to 14.97. The cell prints 14.96. 50,034 divided by 337,724, times 100, is 14.815056, which rounds half-up to 14.82. The cell prints 14.81. 34,564 divided by 235,667, times 100, is 14.666457, which does round to the 14.67 they print. Do not treat the three that miss as the three that hit (Yoganarasimhan, Barzegary, and Pani, Design and Evaluation of Personalized Free Trials).

Table 4 of the same paper swaps the two smaller totals. The 7-day row prints training 35,743 and test 15,274, and the row total is 51,017. 35,743 plus 15,274 is 51,017. The 14-day row prints 35,901 and 15,139, and the row total is 51,040. 35,901 plus 15,139 is 51,040. Table 1 had given 51,040 to 7 days and 51,017 to 14 days. The two tables add, and they do not agree on which arm owns which total. The 30-day row is 165,056 plus 70,611, which is 235,667, matching Table 1. Training plus test is 236,700 plus 101,024, which is 337,724. The sentence above the table says they use 70% for training and 30% for test. 70 percent of 337,724 is 236,406.8. They print 236,700. 30 percent is 101,317.2. They print 101,024. The two printed pieces add to the total, and neither piece is the percentage the sentence names. 236,700 divided by 337,724 is 0.700868, which is not 0.70. A sentence that says 70 percent is not the row you were asked to defend.

Table 5 is a third set of rates, and it does not reproduce Table 1. On the test data the 7-day subscription rate is 0.1544, the 30-day rate is 0.1463, and the printed difference is 0.0082. 0.1544 minus 0.1463 is 0.0081. 0.0081 is not 0.0082. The printed gain is 5.59. 0.0082 divided by 0.1463, times 100, is 5.604921, which is not 5.59. The training row does subtract: 0.1532 minus 0.1468 is 0.0064, which is the difference they print, and the gain they print is 4.34. 0.0064 divided by 0.1468, times 100, is 4.359673, which is not 4.34. The 14-day training difference they print is 0.0021. 0.1490 minus 0.1468 is 0.0022. The test 14-day difference does match: 0.1511 minus 0.1463 is 0.0048. The caption prints the baselines as 14.68 and 14.63. The cells print 0.1468 and 0.1463. 0.1468 times 100 is 14.68, so the caption moved the decimal, and 14.68 is still not Table 1's 14.67. The findings say a lasso policy prescribes the 7-day trial to 69% of users and a causal forest to 91%. A later paragraph says lasso and XGBoost prescribe it to about 70%, and that the forest gives it to over 91%. 69 is not 70. 91 is not a phrase that says over 91. 5.59 on a test gain is not 15.36 on a table, and none of them is trial_end null.

The same paper's other counts are a different scale from a subscription id. Prices run from $30 to $140 a month, and the authors say they multiplied every dollar figure by a constant. A scaled 30 is not 30 days, and it is not unit_amount 1000. Educational licenses are 20.8% of subscriptions. 20.8 is not 15.36. The experiment ran from 1 December 2015 to 6 January 2016, across six markets, on four products. The figure caption then names Australia and New Zealand, France, Germany, Japan, and the United States, and calls that six regions. That list is five names. The United Kingdom is in the experiment sentence and not in the caption. Table 3 prints a subscription mean of 0.148 on 337,724 rows. 0.148 times 100 is 14.8, which is not 14.81. Revenue is reported on 334,223 rows, and subscriber revenue on 46,533 rows. 337,724 minus 334,223 is 3,501. 50,034 minus 46,533 is 3,501. The page does not print 3,501. A repeated gap is not a trial end. The paper says SaaS revenues exceed 200 billion USD and cites Gartner 2019. 200 billion is not 337,724, and it is not the customer on this subscription.

Do the three proofs on one real subscription, in the console that actually holds it. First, the binding. Copy the subscription id, the customer id, and trial_end. If trial_start and trial_end are both null and status is active, write that. Do not infer a 7-day trial because a paper printed 7, and do not infer sub_1MowQVLkdIwHu7ixeRlqHVzs because a sample prints it. If the only date you have is current_period_end, write the period and write that the trial fields were null. A 31-day period is not a trial. Second, the other subscription. A different subscription, with a different customer id, is not this one. A chart of 337,724 other users is not that second subscription. If you cannot show a subscription that is not this trial, you have a counter, not a record. Third, the other account. A list that belongs to someone else does not contain this subscription id. If the only list is a single shared table and you cannot say whose trial it is, write that. A tenant you cannot name is the finding. It is not a reason to tell the buyer the trial was 7 days.

Three moves feel like the proof and are a second problem. Setting trial_end to now because the null was embarrassing, before you have copied the id. The call changes the subscription. It does not tell you what the previous end was if you did not copy it. Quoting 5.59% or 15.36 because one of them looks precise, while the subscription you were asked about is one row, and the 337,724 users who produced those figures had not opened your customer. Asking a model which trial the customer started. The model will pick a plausible day count. It will not open the subscription. A status you have not kept, while the buyer is arguing about access, is which status is that subscription in?. Opening that screen does not name the trial end.

The path is ordinary when an operator can open one subscriber without opening the next subscriber as the way to prove it. PassGlobe is a subscription offers platform: a user dashboard, a vendor dashboard, and an admin dashboard, with weekly Stripe subscriptions and a QR code per subscriber. The shape that matters here is one subscriber you can point at, in an account you administer, distinct from the next subscriber. That case is not a trial ledger. Nothing in the description is a headcount, a duration, or a result figure. If the only control on the screen shows a week's volume and will not name a subscription id, you do not have this proof. You have a chart.

There is a version of this afternoon where hiring the path is the wrong purchase. Nothing is for sale, because the product does not take money yet. You have no product. You are still choosing who will build, and the document in front of you is a term sheet. The criteria for that choice sit on the page written for a top SaaS development company. That page is criteria. It does not rank anyone, including us. The only fact in the room is a paper's gain on other users. 5.59 is not your trial, and 51,040 is not your trial, and 31 days on a sample period is not your trial. A customer has already seen another customer's subscription. Naming an id does not close a leak. Or you wanted a lawyer to say whether a trial is a contract. Hire the lawyer.

When the subscription is real and the console cannot name the trial, the missing object is specific. An admin action, in an account you administer, that shows one subscription id and one trial end or an explicit pair of nulls, shows a different subscription that is not that trial, and shows another account's list without it. A startup software development company that expects this will have put that action next to the rest of the billing screen, before a stranger's complaint is the way you discover the vendor owns the trial. One that needs a call in order for you to see which trial is stored is telling you who holds the clock. If the first slice is a fixed capability, an AI integration sprint is the shape where the acceptance sentence can include the three proofs. If you do not yet know which system stores the subscription, a two-week AI readiness assessment maps the systems. The findings are yours. They are not a promise that a paper's 5.59% applies, and they are not 7.

The role an invite granted, and the chunk a search returned, are different objects: which role did that invite grant? and which chunk did that search return?. Do not record either on this page. A role name is not a trial end. A file id is not a customer id.

Before you tell them the trial started, do the three proofs and write the id. Name the subscription, the customer, and the trial end, or write that the subscription stored no trial. Show a different subscription that is not that trial. Show another account's list that does not hold it. Do not paste a sample period onto a null, and do not ask a model which of the day counts it was. A paper can tell you what it counted on other users, including the two tables that swap 51,040 and 51,017. The binding is the trial you can defend.